В 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, и больше здесь и здесь, которые также могут описывать ту же проблему. К сожалению, эти вопросы не приводят к решению проблемы.

Редактировать 2016-06-02

Если вы пытаетесь найти «Сообщения журнала Upstart» в целом, проверьте /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) не регистрирует в syslog, то есть не вызывает функцию glibc syslog(). Вместо этого Upstart регистрирует в кольцевом буфере ядра, что читает dmesg. Теперь, я не думаю , что это было возможно для пользователей космических процессов для записи в этот буфер, но , видимо , они могут путем записи /dev/kmsg, и это именно то , что делает Upstart. Итак, это первая часть головоломки.

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

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

Теперь вот клинчер: по умолчанию rsyslogd игнорирует сообщения, не связанные с ядром, при чтении сообщений из кольцевого буфера ядра. Соответствующий параметр конфигурации - $KLogPermitNonKernelFacilityпо умолчанию выключен и должен быть включен, если вы хотите, чтобы rsyslogd обрабатывал эти сообщения. Обратите внимание, что остальная часть конфигурации rsyslogd будет обрабатывать все сообщения из кольцевого буфера ядра как имеющие такую kernвозможность, независимо от того, какую функцию они имели в кольцевом буфере ядра.

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

системный журнал

Код можно записать в системный журнал, вызвав функцию glibc syslog(), описанную в man 3 syslog. Видимо эти функции пишут в /dev/log. Код может читать из системного журнала, читая /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()named klogctl(), чтобы облегчить эту путаницу.

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

Ссылки

• http://upstart.ubuntu.com/cookbook/#initctl-log-priority (неверно указано, что Upstart входит в системный журнал)
• https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
• http://www.gnu.org/software/libc/manual/html_node/Overview-of-Syslog.html
• http://www.rsyslog.com/doc/v5-stable/configuration/modules/imklog.html (обратите внимание, что это для версии 5, используемой в Ubuntu 12.04. Эти параметры считаются устаревшими в последних версиях rsyslog)

Я нашел свой в /var/log/upstart/