Si je comprends bien, le noyau Linux se connecte à /proc/kmsg file (principalement des messages liés au matériel) et /dev/log prise? N'importe où ailleurs? D'autres applications sont-elles également capables d'envoyer des messages à /proc/kmsg ou /dev/log ? Enfin, ai-je raison de dire qu'il s'agit du démon syslog (rsyslog , syslog-ng ) qui vérifie les messages de ces deux endroits, puis les distribue à divers fichiers comme /var/log/messages ou /var/log/kern.log ou même un serveur syslog central ?
Réponse acceptée :
Simplifié, ça se passe plus ou moins comme ça :
Le noyau enregistre les messages (en utilisant le printk() fonction) à un tampon en anneau dans l'espace du noyau. Ces messages sont mis à la disposition des applications de l'espace utilisateur de deux manières :via le /proc/kmsg fichier (à condition que /proc est monté), et via le sys_syslog appel système.
Il existe deux applications principales qui lisent (et, dans une certaine mesure, peuvent contrôler) le tampon circulaire du noyau :dmesg(1) et klogd(8) . Le premier est destiné à être exécuté à la demande des utilisateurs, pour imprimer le contenu du tampon circulaire. Ce dernier est un démon qui lit les messages de /proc/kmsg (ou appelle sys_syslog , si /proc n'est pas monté) et les envoie à syslogd(8) , ou à la console. Cela couvre le côté noyau.
Dans l'espace utilisateur, il y a syslogd(8) . Il s'agit d'un démon qui écoute sur un certain nombre de sockets de domaine UNIX (principalement /dev/log , mais d'autres peuvent également être configurés), et éventuellement au port UDP 514 pour les messages. Il reçoit également des messages de klogd(8) (syslogd(8) ne se soucie pas de /proc/kmsg ). Il écrit ensuite ces messages dans certains fichiers dans /log , ou à des canaux nommés, ou les envoie à certains hôtes distants (via le syslog protocole, sur le port UDP 514), tel que configuré dans /etc/syslog.conf .
Les applications de l'espace utilisateur utilisent normalement la libc fonction syslog(3) pour consigner les messages. libc envoie ces messages au socket de domaine UNIX /dev/log (où ils sont lus par syslogd(8) ), mais si une application est chroot(2) -ed les messages pourraient finir par être écrits sur d'autres sockets, par exemple. vers /var/named/dev/log . Il est bien sûr indispensable pour les applications envoyant ces logs et syslogd(8) convenir de l'emplacement de ces prises. Pour ces raisons syslogd(8) peut être configuré pour écouter des sockets supplémentaires en plus du standard /dev/log .
Enfin, le syslog protocole est juste un protocole datagramme. Rien n'empêche une application d'envoyer des datagrammes syslog à n'importe quel socket de domaine UNIX (à condition que ses informations d'identification lui permettent d'ouvrir le socket), en contournant le syslog(3) fonction dans libc totalement. Si les datagrammes sont correctement formatés syslogd(8) peut les utiliser comme si les messages étaient envoyés via syslog(3) .
Bien sûr, ce qui précède ne couvre que la théorie "classique" de la journalisation. D'autres démons (tels que rsyslog et syslog-ng , comme vous le mentionnez) peut remplacer le simple syslogd(8) , et faire toutes sortes de choses astucieuses, comme envoyer des messages à des hôtes distants via des connexions TCP chiffrées, fournir des horodatages haute résolution, etc. Et il y a aussi systemd , qui phagocyte lentement la partie UNIX de Linux. systemd a ses propres mécanismes de journalisation, mais cette histoire devrait être racontée par quelqu'un d'autre. 🙂
Différences avec le monde *BSD :
Sur *BSD, il n'y a pas de klogd(8) , et /proc n'existe pas (sur OpenBSD) ou est pour la plupart obsolète (sur FreeBSD et NetBSD). syslogd(8) lit les messages du noyau depuis le périphérique caractère /dev/klog , et dmesg(1) utilise /dev/kmem pour décoder les noms de noyau. Seul OpenBSD a un /dev/log . FreeBSD utilise deux sockets de domaine UNIX /var/run/log et var/rub/logpriv à la place, et NetBSD a un /var/run/log .