Де містяться повідомлення журналу Upstart на Ubuntu 13.X?


28

У Ubuntu 12.04 я можу знайти повідомлення журналу Upstart /var/log/syslog.

Команди:

# initctl log-priority info
# initctl emit hello

Журнал:

Apr  1 01:56:56 precise64 kernel: [ 8365.820425] init: Connection from private client
Apr  1 01:56:56 precise64 kernel: [ 8365.821130] init: Handling hello event

У Ubuntu 13.10 повідомлення не з’являються syslogні в /var/logкаталозі, ні в іншому місці , хоча команди logger helloпрацюють як слід. Чи варто їх шукати десь ще? Чи є налаштування конфігурації, яке мені потрібно десь змінити?

Є питання про помилку сервера у того, хто, здається, має таку ж проблему на Ubuntu 13.04, і багато іншого тут і тут, що також може описувати ту ж проблему. На жаль, ці питання не призводять до проблеми.

Відповіді:


39

Редагувати 02.06.2016

Якщо ви взагалі намагаєтесь знайти "Початкові повідомлення журналу", поставте прапорець /var/log/upstart/. Ось де Upstart економить stdoutі stderrвід сервісів Upstart. Завдяки відповіді leopd за вказівку на це.

Якщо ви шукаєте повідомлення журналу від самої Upstart, які налаштовані initctl log-priorityта випромінюються initctl emit, читайте далі!

Коротка версія

Записи журналу фактично повинні відображатися у dmesg. Незважаючи на це, вони не відображаються за замовчуванням у /var/log.

Якщо ви хочете, щоб вони /var/logтеж були, додайте $KLogPermitNonKernelFacility onв конфігурацію rsyslogd. Я пропоную створити спеціальний файл, як /etc/rsyslog.d/60-custom.confуникнути редагування /etc/rsyslog.conf, оскільки цим керує dpkg. Тепер Upstart повідомлення повинно відображатися в /var/log/syslog, як тільки ви встановите Upstart - х log-priorityдо infoабо так.

Довга версія

Це взяв мене днів , щоб вистежити, але , по- видимому Upstart (1.5) не НЕ увійти в системний журнал, тобто, він не викликає функцію GLibC syslog(). Натомість Upstart записує в буфер кільця ядра, що читає dmesg. Тепер, я не думаю , що це було можливо для користувачів космічних процесів для запису в цей буфер, але , мабуть , вони можуть шляхом запису /dev/kmsg, і це саме те , що робить Upstart. Так ось перша частина головоломки.

Друга частина полягає в тому, що існує думка, що повідомлення, записані в буфер кільця ядра, автоматично копіюються в syslog ядром (принаймні, так я завжди думав). Виявляється, це насправді робиться демоном простору користувача, традиційно klogd, який працює в тандемі з syslogd. Очевидно, rsyslogd замінює syslogd, але, мабуть, він замінює і klogd (на кшталт: див. Примітки наприкінці).

Третя частина полягає в тому, що повідомлення, записані в буфер кільця ядра з простору користувача, насправді виглядають відмінними від повідомлень, написаних з простору ядра: вони мають іншу функцію. dmesg має декілька варіантів, які взаємодіють із цим: -xпокаже об'єкт (та пріоритет), тоді як -uі -kскаже dmesg, щоб відображати лише повідомлення про об'єкти користувача та повідомлення про об'єкти ядра відповідно.

Тепер ось клінік: rsyslogd за замовчуванням ігнорує повідомлення, що не мають ядра, коли він читає повідомлення з буфера кільця ядра. Відповідна опція конфігурації - це $KLogPermitNonKernelFacility, яка за замовчуванням вимкнена, і її потрібно увімкнути, якщо ви хочете, щоб rsyslogd обробив ці повідомлення. Зауважте, що решта конфігурації rsyslogd буде розглядати всі повідомлення з буфера кільця ядра як такі, що мають kernоб'єкт, незалежно від об'єкта, який вони мали у буфері кільця ядра.

Більше інформації

syslog

Код може записати в syslog, викликавши функцію glibc syslog(), описану в man 3 syslog. Мабуть, ці функції пишуть /dev/log. Код можна прочитати з syslog, прочитавши /dev/log, і саме це syslogdі робить його заміну. rsyslogdзчитує /dev/logза допомогою свого imuxsockвхідного модуля.

Кільцевий буфер ядра

Простір ядра записує в цей буфер, викликаючи функцію ядра printk(), тому його іноді називають буфером printk. Користувацький простір може записати на нього, написавши на /dev/kmsg. Користувацький простір може читати з цього буфера кількома методами: він може читати з /proc/kmsg(що dmesg робить за замовчуванням), або він може читати з /dev/kmsg, або він може викликати системний виклик syslog(), який описаний в man 2 syslogі повністю відрізняється від syslog()описаної функції glibc в man 3 syslog. glibc фактично надає обгортку для системного виклику syslog(), викликаного klogctl(), щоб полегшити цю плутанину.

Традиційно klogdчитає з одного з цих інтерфейсів, а потім викликає функцію glibc, syslog()щоб скопіювати їх у syslog. rsyslogd читає один з цих інтерфейсів через свій imklogвхідний модуль, але AFAIK не заважає викликати glibc syslog(), тому це не зовсім як klogd; він просто обробляє вихід так imklogсамо, як він обробляє вихід з будь-якого іншого модуля введення. Існує додаткове застереження, що весь imklogвихід має kernоб'єкт незалежно від повідомлень про об'єкти, які були в буфері кільця ядра.

Список літератури


4
Дякую за глибоке пояснення, чому це не працює, і як це виправити. Один з відповідей на згадані зв'язані питання, dmesgале це не мало сенсу без контексту, який тут наведено.
Бредд Шоні

16

Я знайшов своє в /var/log/upstart/


Я знайшов своє у файлі, /var/log/upstart/job.logде jobназва моєї роботи.
Кенні Евітт

AFAIK саме туди йдуть stdout / stderr від робочих місць. Це питання стосується повідомлень журналу від самої Upstart, які не пов’язані з жодною конкретною роботою.
Ванесса Фіппс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.