Редактировать 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
средство независимо от того, какие сообщения средства были в кольцевом буфере ядра.
Ссылки
dmesg
но он не имеет никакого смысла без контекста, приведенного здесь.