На Ubuntu 12.04 я могу найти Новомодные сообщения журнала в /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, и больше здесь и здесь который может также описывать ту же проблему. К сожалению, эти вопросы предлагают, не ведет для проблемы.
При попытке найти "Новомодные сообщения журнала" в целом, проверить /var/log/upstart/
. Это - то, где Выскочка сохраняет stdout
и stderr
от Новомодных сервисов. Благодаря ответу leopd для указания на это.
Если Вы ищете сообщения журнала от Выскочки самостоятельно, которые настроены initctl log-priority
и испускаемый initctl emit
, продолжайте читать!
Записи в журнале должны на самом деле обнаружиться в dmesg. Несмотря на это, они не обнаруживаются по умолчанию в /var/log
.
Если Вы хотите их в /var/log
также, добавить $KLogPermitNonKernelFacility on
к конфигурации rsyslogd. Я предлагаю создать пользовательский файл как /etc/rsyslog.d/60-custom.conf
постараться не редактировать /etc/rsyslog.conf
, так как этим управляет dpkg. Теперь Новомодные сообщения должны обнаружиться в /var/log/syslog
, после того как Вы устанавливаете Выскочку log-priority
кому: info
или около этого.
Это взяло меня дни для разыскивания, но по-видимому Выскочка (1.5) не регистрируется к системному журналу, то есть, он не вызывает glibc функцию syslog()
. Вместо этого Выскочка регистрируется к кольцевому буферу ядра, который является тем, что читает dmesg. Теперь, я не думал, что для процессов пространства пользователя было возможно записать в тот буфер, но по-видимому они могут путем записи в /dev/kmsg
, и это точно, что делает Выскочка. Таким образом, это - первая часть загадки.
Вторая часть - то, что существует распространенное мнение, что сообщения, записанные в кольцевой буфер ядра, автоматически копируются в системный журнал ядром (по крайней мере это - то, что я всегда думал). Оказывается, что это на самом деле сделано демоном пространства пользователя, традиционно 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
и полностью отличается от функции glibc syslog()
описанный в man 3 syslog
. glibc на самом деле предоставляет обертку системному вызову syslog()
, названный klogctl()
, помочь облегчить этот беспорядок.
Традиционно, klogd
чтения от одного из этих интерфейсов, затем вызывает glibc функцию syslog()
скопировать их в системный журнал. rsyslogd прочитывает один из этих интерфейсов imklog
входной модуль, но AFAIK не потрудился называть glibc syslog()
, который является, почему это точно не похоже на klogd; это просто обрабатывает вывод imklog
точно так же, как это обрабатывает вывод от любого другого входного модуля. Существует добавленный протест что все imklog
вывод имеет kern
средство независимо от сообщений средства имело в кольцевом буфере ядра.