Soweit ich weiß, loggt sich der Linux-Kernel in /proc/kmsg ein Datei (hauptsächlich hardwarebezogene Meldungen) und /dev/log Steckdose? Irgendwo anders? Können auch andere Anwendungen Nachrichten an /proc/kmsg senden oder /dev/log ? Zu guter Letzt habe ich Recht, dass es sich um den Syslog-Daemon handelt (rsyslog , syslog-ng ), das Nachrichten von diesen beiden Stellen prüft und diese dann an verschiedene Dateien wie /var/log/messages verteilt oder /var/log/kern.log oder gar zentraler Syslog-Server?
Akzeptierte Antwort:
Vereinfacht geht das ungefähr so:
Der Kernel protokolliert Meldungen (unter Verwendung von printk() Funktion) in einen Ringpuffer im Kernelspace. Diese Nachrichten werden User-Space-Anwendungen auf zwei Arten zur Verfügung gestellt:über /proc/kmsg Datei (vorausgesetzt, dass /proc gemountet ist) und über das sys_syslog Systemaufruf.
Es gibt zwei Hauptanwendungen, die den Ringpuffer des Kernels lesen (und bis zu einem gewissen Grad steuern können):dmesg(1) und klogd(8) . Ersteres soll von Benutzern bei Bedarf ausgeführt werden, um den Inhalt des Ringpuffers auszudrucken. Letzteres ist ein Daemon, der die Nachrichten von /proc/kmsg liest (oder ruft sys_syslog auf , wenn /proc ist nicht gemountet) und sendet sie an syslogd(8) , oder zur Konsole. Das deckt die Kernelseite ab.
Im User Space gibt es syslogd(8) . Dies ist ein Daemon, der auf einer Reihe von UNIX-Domain-Sockets lauscht (hauptsächlich /dev/log , aber auch andere können konfiguriert werden) und optional an den UDP-Port 514 für Nachrichten. Es empfängt auch Nachrichten von klogd(8) (syslogd(8) kümmert sich nicht um /proc/kmsg ). Anschließend schreibt es diese Meldungen in einige Dateien in /log , oder an Named Pipes, oder sendet sie an entfernte Hosts (über das syslog Protokoll, auf UDP-Port 514), wie in /etc/syslog.conf konfiguriert .
User-Space-Anwendungen verwenden normalerweise die libc Funktion syslog(3) Nachrichten zu protokollieren. libc sendet diese Meldungen an den UNIX-Domain-Socket /dev/log (wo sie von syslogd(8) gelesen werden ), aber wenn eine Anwendung chroot(2) ist -ed werden die Nachrichten möglicherweise in andere Sockets geschrieben, z. nach /var/named/dev/log . Es ist natürlich wichtig für die Anwendungen, die diese Protokolle und syslogd(8) senden sich über die Position dieser Steckdosen zu einigen. Aus diesem Grund syslogd(8) kann so konfiguriert werden, dass neben dem standardmäßigen /dev/log auch zusätzliche Sockets abgehört werden .
Schließlich das syslog Das Protokoll ist nur ein Datagrammprotokoll. Nichts hindert eine Anwendung daran, Syslog-Datagramme an einen beliebigen UNIX-Domänen-Socket zu senden (vorausgesetzt, dass ihre Anmeldeinformationen es ihr ermöglichen, den Socket zu öffnen), indem sie syslog(3) umgehen Funktion in libc ganz und gar. Wenn die Datagramme korrekt formatiert sind syslogd(8) kann sie verwenden, als ob die Nachrichten durch syslog(3) gesendet würden .
Das Obige deckt natürlich nur die „klassische“ Logging-Theorie ab. Andere Daemons (wie rsyslog und syslog-ng , wie Sie bereits erwähnt haben) kann den einfachen syslogd(8) ersetzen , und machen alle möglichen raffinierten Dinge, wie das Senden von Nachrichten an entfernte Hosts über verschlüsselte TCP-Verbindungen, das Bereitstellen von hochauflösenden Zeitstempeln und so weiter. Und es gibt auch systemd , das den UNIX-Teil von Linux langsam phagozytiert. systemd hat seine eigenen Protokollierungsmechanismen, aber diese Geschichte müsste von jemand anderem erzählt werden. 🙂
Unterschiede zur *BSD-Welt:
Auf *BSD gibt es kein klogd(8) , und /proc entweder existiert nicht (auf OpenBSD) oder ist größtenteils veraltet (auf FreeBSD und NetBSD). syslogd(8) liest Kernel-Meldungen vom Zeichengerät /dev/klog , und dmesg(1) verwendet /dev/kmem um Kernelnamen zu entschlüsseln. Nur OpenBSD hat ein /dev/log . FreeBSD verwendet zwei UNIX-Domain-Sockets /var/run/log und var/rub/logpriv stattdessen und NetBSD hat ein /var/run/log .