Где Новомодные сообщения журнала на Ubuntu 13. X?

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

28
задан 13 April 2017 в 05:25

2 ответа

Редактирование 02.06.2016

При попытке найти "Новомодные сообщения журнала" в целом, проверить /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 средство независимо от сообщений средства имело в кольцевом буфере ядра.

Ссылки

39
ответ дан 23 November 2019 в 00:56

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

16
ответ дан 23 November 2019 в 00:56

Другие вопросы по тегам:

Похожие вопросы: