Jak jsem pochopil, linuxové jádro se přihlásí do /proc/kmsg soubor (většinou zprávy související s hardwarem) a /dev/log zásuvka? Kdekoliv jinde? Jsou jiné aplikace také schopny posílat zprávy na /proc/kmsg nebo /dev/log ? V neposlední řadě mám pravdu, že je to démon syslog (rsyslog , syslog-ng ), která kontroluje zprávy z těchto dvou míst a poté je distribuuje do různých souborů, jako je /var/log/messages nebo /var/log/kern.log nebo dokonce centrální syslog server?
Přijatá odpověď:
Zjednodušeně to vypadá víceméně takto:
Jádro zaznamenává zprávy (pomocí printk() funkce) do kruhové vyrovnávací paměti v prostoru jádra. Tyto zprávy jsou zpřístupněny aplikacím v uživatelském prostoru dvěma způsoby:prostřednictvím /proc/kmsg soubor (za předpokladu, že /proc je připojen) a prostřednictvím sys_syslog systémové volání.
Existují dvě hlavní aplikace, které čtou (a do určité míry mohou ovládat) kruhovou vyrovnávací paměť jádra:dmesg(1) a klogd(8) . První jmenovaný je určen ke spuštění na vyžádání uživateli, k tisku obsahu kruhové vyrovnávací paměti. Poslední jmenovaný je démon, který čte zprávy z /proc/kmsg (nebo volá sys_syslog , pokud /proc není připojen) a odešle je do syslogd(8) nebo do konzole. To pokrývá stranu jádra.
V uživatelském prostoru je syslogd(8) . Toto je démon, který naslouchá na řadě soketů domény UNIX (hlavně /dev/log , ale lze konfigurovat i jiné) a volitelně na UDP port 514 pro zprávy. Také přijímá zprávy z klogd(8) (syslogd(8) nezajímá /proc/kmsg ). Tyto zprávy pak zapisuje do některých souborů v /log , nebo do pojmenovaných kanálů nebo je odesílá na některé vzdálené hostitele (přes syslog protokol, na portu UDP 514), jak je nakonfigurováno v /etc/syslog.conf .
Aplikace v uživatelském prostoru běžně používají libc funkce syslog(3) k protokolování zpráv. libc odesílá tyto zprávy do soketu domény UNIX /dev/log (kde jsou čteny pomocí syslogd(8) ), ale pokud je aplikace chroot(2) -ed zprávy mohou skončit zapsány do jiných soketů, např. na /var/named/dev/log . Pro aplikace odesílající tyto logy a syslogd(8) je to samozřejmě nezbytné dohodnout umístění těchto zásuvek. Z tohoto důvodu syslogd(8) lze nakonfigurovat tak, aby naslouchal dalším soketům kromě standardního /dev/log .
Nakonec syslog protokol je pouze datagramový protokol. Nic nebrání aplikaci v odesílání datagramů syslog do libovolného soketu domény UNIX (za předpokladu, že jí její pověření umožňují soket otevřít), čímž se obejde syslog(3) funkce v libc zcela. Pokud jsou datagramy správně naformátovány syslogd(8) můžete je použít, jako by byly zprávy odeslány přes syslog(3) .
Výše uvedené samozřejmě pokrývá pouze „klasickou“ teorii protokolování. Ostatní démoni (jako rsyslog a syslog-ng , jak jste zmínil) může nahradit prostý syslogd(8) a dělat nejrůznější šikovné věci, jako je posílání zpráv vzdáleným hostitelům přes šifrovaná TCP spojení, poskytování časových razítek ve vysokém rozlišení a tak dále. A je tu také systemd , který pomalu fagocytuje unixovou část Linuxu. systemd má své vlastní logovací mechanismy, ale ten příběh by musel vyprávět někdo jiný. 🙂
Rozdíly se světem *BSD:
Na *BSD není žádný klogd(8) a /proc buď neexistuje (na OpenBSD), nebo je většinou zastaralý (na FreeBSD a NetBSD). syslogd(8) čte zprávy jádra ze znakového zařízení /dev/klog a dmesg(1) používá /dev/kmem k dekódování názvů jader. Pouze OpenBSD má /dev/log . FreeBSD používá dva sokety domény UNIX /var/run/log a var/rub/logpriv místo toho a NetBSD má /var/run/log .