W systemie Ubuntu 12.04 mogę znaleźć komunikaty dziennika Upstart w /var/log/syslog.

Polecenia:

# initctl log-priority info
# initctl emit hello

Log:

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

W systemie Ubuntu 13.10 komunikaty nie pojawiają się w katalogu syslogani nigdzie indziej w /var/logkatalogu, chociaż polecenia logger hellodziałają zgodnie z oczekiwaniami. Czy powinienem ich szukać gdzie indziej? Czy jest jakieś ustawienie konfiguracji, które muszę gdzieś zmienić?

Jest to pytanie na serwerze Fault od kogoś, kto wydaje się mieć ten sam problem na Ubuntu 13.04, a więcej tutaj i tutaj , że może być również opisujące ten sam problem. Niestety te pytania nie zawierają wskazówek dotyczących problemu.

Edytuj 2016-06-02

Jeśli ogólnie próbujesz znaleźć „Uaktualnij komunikaty dziennika”, sprawdź /var/log/upstart/. To tam zapisuje Upstart stdouti stderrusługi Upstart. Dzięki odpowiedzi leopd za zwrócenie na to uwagi.

Jeśli szukasz komunikatów dziennika od samego Upstart, które są konfigurowane initctl log-priorityi wysyłane przez initctl emit, czytaj dalej!

Krótka wersja

Wpisy do dziennika powinny faktycznie pojawić się w dmesg. Mimo to domyślnie nie pojawiają się w /var/log.

Jeśli też chcesz je /var/logdodać, dodaj $KLogPermitNonKernelFacility ondo konfiguracji rsyslogd. Sugeruję utworzenie niestandardowego pliku, takiego jak /etc/rsyslog.d/60-custom.confunikanie edycji /etc/rsyslog.conf, ponieważ zarządza nim dpkg. Teraz dorobkiewicz komunikaty powinny pokazać się w /var/log/syslogpo ustawieniu Upstart na log-prioritycelu infoalbo tak.

Długa wersja

Śledzenie zajęło mi kilka dni, ale najwyraźniej Upstart (1.5) nie loguje się do syslog, czyli nie wywołuje funkcji glibc syslog(). Zamiast tego Upstart loguje się do bufora pierścieniowego jądra, który odczytuje dmesg. Teraz, ja nie sądzę, że było to możliwe dla procesów przestrzeni użytkownika napisać do tego bufora, ale najwyraźniej potrafią pisząc /dev/kmsg, i to jest dokładnie to, co robi Upstart. To pierwsza część układanki.

Drugą częścią jest powszechne przekonanie, że wiadomości zapisane w buforze pierścieniowym jądra są automatycznie kopiowane do syslog przez jądro (przynajmniej tak zawsze myślałem). Okazuje się, że w rzeczywistości robi to demon przestrzeni użytkownika, tradycyjnie klogd, który działa w parze z syslogd. Oczywiście rsyslogd zastępuje syslogd, ale najwyraźniej zastępuje również klogd (rodzaj: patrz uwagi na końcu).

Trzecia część polega na tym, że wiadomości zapisane do bufora pierścienia jądra z przestrzeni użytkownika wyglądają inaczej niż wiadomości napisane z przestrzeni jądra: mają inną funkcję. dmesg ma kilka opcji, które oddziałują z tym: -xpokaże siłownia (i priorytet), podczas -ui -kpowiedzieć dmesg, aby wyświetlić tylko wiadomości facility użytkowników i wiadomości facility jądro, odpowiednio.

Oto klinkier: domyślnie rsyslogd ignoruje wiadomości z funkcją inną niż jądro podczas odczytywania wiadomości z bufora pierścieniowego jądra. Odpowiednią opcją konfiguracji jest $KLogPermitNonKernelFacility, która jest domyślnie wyłączona i musi być włączona, jeśli chcesz, aby rsyslogd przetwarzał te wiadomości. Zauważ, że reszta konfiguracji rsyslogd będzie traktować wszystkie wiadomości z bufora pierścieniowego jądra jako posiadające taką funkcję kern, niezależnie od tego, jaką funkcję miały w buforze pierścieniowym jądra.

Więcej informacji

syslog

Kod może zapisywać do syslog, wywołując funkcję glibc syslog()opisaną w man 3 syslog. Najwyraźniej te funkcje piszą do /dev/log. Kod może czytać z syslog, czytając /dev/logi to właśnie robi syslogdi jego zamienniki. rsyslogdczyta /dev/logużywając swojego imuxsockmodułu wejściowego.

Bufor pierścieniowy jądra

Przestrzeń jądra zapisuje w tym buforze, wywołując funkcję jądra printk(), dlatego czasami nazywana jest buforem printk. Przestrzeń użytkownika może do niej pisać, pisząc na /dev/kmsg. Przestrzeń użytkownika może czytać z tego bufora na kilka sposobów: może czytać z /proc/kmsg(co domyślnie robi dmesg) lub może czytać z /dev/kmsglub może wywoływać wywołanie systemowe syslog(), które jest opisane w man 2 syslogi jest całkowicie różne od syslog()opisanej funkcji glibc w man 3 syslog. glibc faktycznie zapewnia otoki wywołania systemowego syslog(), wywoływanego klogctl(), aby złagodzić to zamieszanie.

Tradycyjnie klogdczyta z jednego z tych interfejsów, a następnie wywołuje funkcję glibc w syslog()celu skopiowania ich do syslog. rsyslogd czyta jeden z tych interfejsów przez swój imklogmoduł wejściowy, ale AFAIK nie zawraca sobie głowy wywołaniem glibc syslog(), dlatego nie jest dokładnie taki jak klogd; po prostu przetwarza dane wyjściowe, imklogtak jak przetwarza dane wyjściowe z dowolnego innego modułu wejściowego. Dodano dodatkowe zastrzeżenie, że wszystkie imklogdane wyjściowe mają funkcję kernniezależnie od komunikatów funkcji w buforze pierścienia jądra.

Referencje

• http://upstart.ubuntu.com/cookbook/#initctl-log-priority (niepoprawnie stwierdza, że ​​Upstart loguje się do syslog)
• 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 (Należy pamiętać, że dotyczy to wersji 5 używanej w systemie Ubuntu 12.04. Te opcje są uważane za starsze w najnowszych wersjach rsyslog)

Znalazłem mój w /var/log/upstart/