Unter Ubuntu 12.04 finde ich Upstart-Protokollmeldungen in /var/log/syslog .
Befehle:
# initctl log-priority info
# initctl emit hello
Protokoll:
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
Unter Ubuntu 13.10 erscheinen die Meldungen nicht im syslog oder irgendwo anders unter /var/log Verzeichnis, obwohl Befehle wie logger hello funktionieren wie erwartet. Soll ich sie woanders suchen? Gibt es eine Konfigurationseinstellung, die ich irgendwo ändern muss?
Es gibt eine Frage zu Server Fault von jemandem, der das gleiche Problem unter Ubuntu 13.04 zu haben scheint, und mehr hier und hier, die möglicherweise auch das gleiche Problem beschreiben. Leider bieten diese Fragen keine Anhaltspunkte für das Problem.
Beste Antwort
Bearbeiten 2016-06-02
Wenn Sie versuchen, „Upstart-Protokollmeldungen“ im Allgemeinen zu finden, überprüfen Sie /var/log/upstart/ . Dort speichert Upstart stdout und stderr von Upstart-Diensten. Danke an leopds Antwort für den Hinweis.
Wenn Sie nach Protokollmeldungen von Upstart selbst suchen, die von initctl log-priority konfiguriert werden und von initctl emit ausgegeben , lesen Sie weiter!
Kurzfassung
Die Log-Einträge sollten eigentlich in dmesg erscheinen. Trotzdem nicht werden standardmäßig in /var/log angezeigt .
Wenn Sie sie wollen in /var/log fügen Sie auch $KLogPermitNonKernelFacility on hinzu zu rsyslogds config. Ich schlage vor, eine benutzerdefinierte Datei wie /etc/rsyslog.d/60-custom.conf zu erstellen um die Bearbeitung von /etc/rsyslog.conf zu vermeiden , da diese von dpkg verwaltet wird. Jetzt sollten Upstart-Meldungen in /var/log/syslog erscheinen , sobald Sie die log-priority von Upstart festgelegt haben zu info oder so.
Lange Version
Ich brauchte Tage, um das aufzuspüren, aber anscheinend tut Upstart (1.5) nicht log in Syslog, das heißt, es ruft nicht die glibc-Funktion syslog() auf . Stattdessen protokolliert Upstart den Kernel-Ringpuffer, den dmesg liest. Nun, ich hielt es nicht für möglich für Benutzerraumprozesse, um in diesen Puffer zu schreiben, aber anscheinend können sie das, indem sie nach /dev/kmsg schreiben , und genau das macht Upstart. Das ist also der erste Teil des Puzzles.
Der zweite Teil ist, dass es eine weit verbreitete Meinung gibt, dass Nachrichten, die in den Kernel-Ringpuffer geschrieben werden, vom Kernel automatisch in Syslog kopiert werden (zumindest dachte ich das immer). Es stellt sich heraus, dass dies tatsächlich von einem Userspace-Daemon erledigt wird, traditionell klogd, der zusammen mit syslogd arbeitet. Offensichtlich ersetzt rsyslogd syslogd, aber anscheinend ersetzt es auch klogd (sozusagen:siehe Anmerkungen am Ende).
Der dritte Teil ist, dass Nachrichten, die aus dem Benutzerraum in den Kernel-Ringpuffer geschrieben werden, tatsächlich anders aussehen als Nachrichten, die aus dem Kernel-Raum geschrieben werden:Sie haben eine andere Einrichtung. dmesg hat einige Optionen, die damit interagieren:-x zeigt die Einrichtung (und die Priorität), während -u und -k Sagen Sie dmesg, dass es nur Benutzer-Facility-Meldungen bzw. Kernel-Facility-Meldungen anzeigen soll.
Hier ist der Clou:Standardmäßig ignoriert rsyslogd Nachrichten mit einer Nicht-Kernel-Einrichtung, wenn Nachrichten aus dem Ringpuffer des Kernels gelesen werden. Die relevante Konfigurationsoption ist $KLogPermitNonKernelFacility , die standardmäßig deaktiviert ist und aktiviert werden muss, wenn Sie möchten, dass rsyslogd diese Nachrichten verarbeitet. Beachten Sie, dass der Rest der Konfiguration von rsyslogd alle Nachrichten aus dem Kernel-Ringpuffer so behandeln wird, als hätten sie den kern Einrichtung, unabhängig von der Einrichtung, die sie im Ringpuffer des Kernels hatten.
Weitere Informationen
syslog
Code kann in Syslog schreiben, indem er die glibc-Funktion syslog() aufruft , beschrieben in man 3 syslog . Anscheinend schreiben diese Funktionen in /dev/log . Code kann aus Syslog lesen, indem /dev/log gelesen wird , und das ist syslogd und seine Ersetzungen tun. rsyslogd liest /dev/log mit seinem imuxsock Eingangsmodul.
Kernel-Ringpuffer
Der Kernelspace schreibt in diesen Puffer, indem er die Kernelfunktion printk() aufruft , daher wird es manchmal als printk-Puffer bezeichnet. Der Benutzerbereich kann darauf schreiben, indem er in /dev/kmsg schreibt . Der Benutzerbereich kann auf verschiedene Weise aus diesem Puffer lesen:Er kann aus /proc/kmsg lesen (was dmesg standardmäßig macht), oder es kann aus /dev/kmsg lesen , oder es kann den Systemaufruf syslog() aufrufen , das in man 2 syslog beschrieben wird und ist völlig anders aus der Glibc-Funktion syslog() beschrieben in man 3 syslog . glibc stellt tatsächlich einen Wrapper für den Systemaufruf syslog() bereit , genannt klogctl() , um diese Verwirrung zu beseitigen.
Traditionell klogd liest von einer dieser Schnittstellen und ruft dann die glibc-Funktion syslog() auf um sie in das Syslog zu kopieren. rsyslogd liest eine dieser Schnittstellen durch sein imklog Eingabemodul, aber AFAIK macht sich nicht die Mühe, die glibc syslog() aufzurufen , weshalb es nicht genau wie klogd ist; es verarbeitet nur die Ausgabe von imklog genauso wie es die Ausgabe von jedem anderen Eingabemodul verarbeitet. Es gibt die zusätzliche Einschränkung, dass alle imklog Ausgabe hat den kern Einrichtung, unabhängig von der Einrichtung, die Nachrichten im Ringpuffer des Kernels hatten.
Referenzen
- http://upstart.ubuntu.com/cookbook/#initctl-log-priority (gibt fälschlicherweise an, dass Upstart in Syslog protokolliert)
- 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 (Beachten Sie, dass dies für v5 ist, das in Ubuntu 12.04 verwendet wird. Diese Optionen gelten in neueren rsyslog-Versionen als veraltet)