A quanto ho capito, il kernel Linux accede al /proc/kmsgfile (principalmente messaggi relativi all'hardware) e al /dev/logsocket? Da qualsiasi altra parte? Altre applicazioni sono anche in grado di inviare messaggi a /proc/kmsgo /dev/log? Ultimo ma non meno importante, ho ragione che è il demone syslog ( rsyslog , syslog-ng ) che controlla i messaggi da quei due posti e poi li distribuisce a vari file come /var/log/messageso /var/log/kern.logo persino al server centrale di syslog?
Risposte:
Semplificato, va più o meno così:
Il kernel registra i messaggi (usando la printk()funzione) in un buffer ad anello nello spazio del kernel. Questi messaggi sono resi disponibili per le applicazioni dello spazio utente in due modi: tramite il /proc/kmsgfile (a condizione che /procsia montato) e tramite la sys_syslogsyscall.
Esistono due applicazioni principali che leggono (e, in una certa misura, possono controllare) il ring buffer del kernel: dmesg(1)e klogd(8). Il primo è progettato per essere eseguito su richiesta dagli utenti, per stampare il contenuto del ring buffer. Quest'ultimo è un demone che legge i messaggi da /proc/kmsg(o chiama sys_syslog, se /procnon è montato) e li invia a syslogd(8), o alla console. Quello copre il lato del kernel.
Nello spazio utente, c'è syslogd(8). Questo è un demone che ascolta un numero di socket di dominio UNIX (principalmente /dev/log, ma anche altri possono essere configurati), e facoltativamente alla porta UDP 514 per i messaggi. Riceve anche messaggi da klogd(8)( syslogd(8)non importa /proc/kmsg). Quindi scrive questi messaggi in alcuni file /logo in named pipe o li invia ad alcuni host remoti (tramite il syslogprotocollo, sulla porta UDP 514), come configurato in /etc/syslog.conf.
Le applicazioni dello spazio utente normalmente utilizzano la libcfunzione syslog(3)per registrare i messaggi. libcinvia questi messaggi al socket del dominio UNIX /dev/log(dove sono letti da syslogd(8)), ma se un'applicazione è chroot(2)coperta, i messaggi potrebbero finire per essere scritti in altri socket, per esempio /var/named/dev/log. È, ovviamente, essenziale per le applicazioni che inviano questi registri e syslogd(8)concordare la posizione di questi socket. Per questo motivo syslogd(8)può essere configurato per l'ascolto di prese aggiuntive oltre allo standard /dev/log.
Infine, il syslogprotocollo è solo un protocollo datagramma. Nulla impedisce a un'applicazione di inviare datagrammi syslog a qualsiasi socket di dominio UNIX (a condizione che le sue credenziali gli consentano di aprire il socket), ignorando completamente la syslog(3)funzione libc. Se i datagrammi sono formattati correttamente, syslogd(8)puoi usarli come se i messaggi fossero inviati syslog(3).
Naturalmente, quanto sopra copre solo la teoria del logging "classica". Altri daemon (come rsysloge syslog-ng, come dici tu) possono sostituire la pianura syslogd(8)e fare ogni sorta di cose ingegnose, come inviare messaggi a host remoti tramite connessioni TCP crittografate, fornire timestamp ad alta risoluzione e così via. E c'è anche systemd, che sta lentamente fagocitando la parte UNIX di Linux. systemdha i suoi meccanismi di registrazione, ma quella storia dovrebbe essere raccontata da qualcun altro. :)
Differenze con il mondo * BSD:
Su * BSD non c'è klogd(8), e /proco non esiste (su OpenBSD) o è per lo più obsoleto (su FreeBSD e NetBSD). syslogd(8)legge i messaggi del kernel dal dispositivo a caratteri /dev/kloge lo dmesg(1)usa /dev/kmemper decodificare i nomi del kernel. Solo OpenBSD ha un /dev/log. FreeBSD usa due socket di dominio UNIX /var/run/loge var/rub/logprivinvece, e NetBSD ha un /var/run/log.
rsyslognon lo usa klogd(8)perché le sue radici risalgono a molto tempo fa, non perché recentemente ha preso una decisione esplicita di eliminarlo. La mia memoria può però fallire. Ad ogni modo, come ho detto, stavo solo cercando di coprire la registrazione "classica".
rsyslogdesecuzione e un Ubuntu 12.04 con in syslog-ngesecuzione ed entrambi avevano il file /proc/kmsgaperto secondo lsof, cioè klogdnon era usato. Un'altra cosa interessante che ho notato è che i messaggi di log sono archiviati in /proc/kmsgfile se non è in esecuzione alcun demone syslog e si possono visualizzare quelli con ad esempio cato l'editor di testo. Tuttavia, è possibile visualizzare questi messaggi solo una volta perché scompaiono dopo la visualizzazione. Ultimo ma non meno importante, l'esecuzione dmesgnon cancella il contenuto del /proc/kmsgfile.
/proc/kmsgnon è un file normale, non c'è nulla di "memorizzato" lì, piuttosto è solo una vista del buffer dell'anello del kernel. Puoi leggerlo con catprecisione perché non hai alcuna klogd(8)corsa (se dovessi correre klogd(8), cat /proc/kmsgbloccherei). dmesg(1)legge i messaggi /dev/kmsgpiuttosto che /proc/kmsg; e può anche cancellare il buffer se lo dici a.
systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)- Per favore, dillo, hai talento :-)
L'altra risposta spiega, come dice l'autore, la "registrazione classica" in Linux. Al giorno d'oggi non è così che funzionano le cose in molti sistemi.
I meccanismi del kernel sono cambiati.
Il kernel genera l'output in un buffer in memoria. I software applicativi possono accedervi in due modi. Il sottosistema di registrazione di solito accede ad esso come uno pseudo-FIFO denominato /proc/kmsg. Questa fonte di informazioni sui registri non può essere utilmente condivisa tra i lettori di registri, poiché è di sola lettura. Se più processi lo condividono, ognuno ottiene solo una parte del flusso di dati del registro del kernel. È anche di sola lettura.
L'altro modo per accedervi è il /dev/kmsgdispositivo personaggio più recente . Questa è un'interfaccia di lettura-scrittura condivisibile tra più processi client. Se più processi lo condividono, leggono tutti lo stesso flusso di dati completo, non influenzati l'uno dall'altro. Se lo aprono per l'accesso in scrittura, possono anche iniettare messaggi nel flusso di log del kernel, come se fossero stati generati dal kernel.
/proc/kmsge /dev/kmsgfornire i dati di registro in un formato non RFC-5424.
Le applicazioni sono cambiate.
La syslog()funzione della libreria GNU C nei principali tentativi di connettersi a un AF_LOCALsocket di datagramma denominato /dev/loge scrivere voci di registro su di esso. (La syslog()funzione della libreria BSD C al giorno d'oggi utilizza /var/run/logcome nome socket e prova per /var/run/logprivprima.) Le applicazioni possono ovviamente avere il proprio codice per farlo direttamente. Dopotutto, la funzione di libreria è solo il codice (per aprire, connettersi, scrivere e chiudere un socket) in esecuzione nel contesto del processo stesso dell'applicazione.
Le applicazioni possono anche inviare messaggi RFC 5424 tramite UDP a un server RFC 5426 locale, se uno è in ascolto su un socket AF_INET/ AF_INET6datagram sulla macchina.
Grazie alla pressione del mondo dei demoni nel corso degli ultimi due decenni, molti demoni supportano l'esecuzione in una modalità in cui non usano la syslog()funzione di libreria GNU C o socket UDP, ma sputano i loro dati di registro in errori standard nel ordinaria moda Unix.
Con la famiglia di set di strumenti daemontools c'è molta flessibilità nella registrazione. Ma in generale in tutta la famiglia l'idea è che ogni demone "principale" ha un demone "logging" associato. i demoni "principali" funzionano esattamente come i processi non demoni e scrivono i loro messaggi di log in errori standard (o output standard), che il sottosistema di gestione del servizio organizza per essere collegati tramite una pipe (che mantiene aperti in modo da non perdere i dati del log un riavvio del servizio) nell'input standard del demone "logging".
Tutti i demoni "logging" eseguono un programma che registra da qualche parte . Generalmente questo programma è qualcosa di simile multilogo cyclogche legge dal suo input standard e scrive i file di registro (con timestamp di nanosecondi) in una directory strettamente limitata, ruotata automaticamente, di scrittura esclusiva. In generale, anche questi demoni corrono sotto l'egida di singoli account utente non privilegiati dedicati.
Quindi si finisce con un sistema di registrazione ampiamente distribuito, con i dati di registro di ciascun servizio elaborati separatamente.
Si può eseguire qualcosa di simile klogdo syslogdo rsyslogdsotto una gestione dei servizi della famiglia demoniols. Ma il mondo dei demonoli ha capito molti anni fa che la struttura di gestione dei servizi con demoni "logging" si presta abbastanza bene a fare le cose in modo più semplice. Non è necessario eseguire il fan tutti i flussi di log in un gigantesco mish-mash, analizzare i dati del log e quindi eseguire il fan out dei flussi in file di log separati; e quindi (in alcuni casi) imbullonare un meccanismo di rotazione del registro esterno inaffidabile sul lato. La struttura della famiglia dei daemontools come parte della sua gestione dei log standard fa già la rotazione del log, la scrittura del file di log e la separazione del flusso.
Inoltre: il modello di caricamento a catena dei privilegi di rilascio con strumenti comuni a tutti i servizi significa che i programmi di registrazione non hanno bisogno di privilegi di superutente; e il modello UCSPI significa che devono solo preoccuparsi delle differenze come il flusso rispetto ai trasporti di datagrammi.
Il set di strumenti nosh ne è un esempio. Mentre uno può essere eseguito rsyslogdsotto di esso, fuori dalla scatola, e gestire semplicemente il kernel /run/loge l'input del log UDP alla vecchia maniera; ma anche fornisce più modi "daemontools nativi" di logging queste cose:
klogdservizio che legge /proc/kmsge scrive semplicemente quel flusso di log nel suo errore standard. Questo viene fatto da un semplice programma chiamato klog-read. Il dæmon di registrazione associato alimenta il flusso di registro sul suo input standard in una /var/log/sv/klogddirectory di registro.local-syslog-readservizio che legge datagrammi da /dev/log( /run/logsui BSD) e scrive semplicemente quel flusso di log nel suo errore standard. Questo viene fatto da un programma chiamato syslog-read. Il dæmon di registrazione associato alimenta il flusso di registro sul suo input standard in una /var/log/sv/local-syslog-readdirectory di registro.udp-syslog-readservizio in ascolto sulla porta syslog di UDP, legge ciò che gli viene inviato e scrive semplicemente quel flusso di log nel suo errore standard. Ancora una volta, il programma è syslog-read. Il dæmon di registrazione associato alimenta il flusso di registro sul suo input standard in una /var/log/sv/udp-syslog-readdirectory di registro.local-priv-syslog-readservizio che legge datagrammi /run/logprive scrive semplicemente quel flusso di log nel suo errore standard. Ancora una volta, il programma è syslog-read. Il dæmon di registrazione associato alimenta il flusso di registro sul suo input standard in una /var/log/sv/local-priv-syslog-readdirectory di registro.Il set di strumenti include anche uno export-to-rsyslogstrumento in grado di monitorare una o più directory di registro (utilizzando un sistema di cursori di registro non intrusivo ) e inviare nuove voci in formato RFC 5424 attraverso la rete a un server RFC 5426 designato.
systemd ha un unico programma di gestione dei log monolitico, systemd-journald. Questo funziona come un servizio gestito da systemd.
/dev/kmsgdati di registro del kernel./dev/log(un collegamento simbolico a /run/systemd/journal/dev-log) per i dati del registro dell'applicazione dalla syslog()funzione della libreria GNU C.AF_LOCALsocket del flusso su /run/systemd/journal/stdoutper i dati di registro provenienti dai servizi gestiti da systemd.AF_LOCALsocket del datagramma i /run/systemd/journal/socketdati di registro provenienti da programmi che parlano il protocollo journal specifico del sistema (es. sd_journal_sendv()Et al.)./run/log/journal/o /var/log/journal/.AF_LOCALsocket di datagramma /run/systemd/journal/syslog, scrive lì i dati del diario, se è configurato l'inoltro a syslog./dev/kmsgmeccanismo scrivibile .Le cose brutte accadono a livello di sistema se questo programma si arresta in modo anomalo o il servizio viene arrestato.
systemd stesso organizza che gli output standard e gli errori di (alcuni) servizi siano collegati al /run/systemd/journal/stdoutsocket. Quindi i demoni che registrano l'errore standard nel modo normale vengono inviati al diario.
Ciò soppianta completamente klogd, syslogd, syslog-ng e rsyslogd.
Questi devono ora essere specifici del sistema. Su un sistema systemd non diventano la fine del server /dev/log. Invece, adottano uno dei due approcci:
/run/systemd/journal/syslog, che (se ricordi) systemd-journaldtenta di connettersi e scrivere i dati del diario. Un paio di anni fa, si sarebbe configurato il imuxsockmetodo di input di rsyslogd per farlo.imjournalmetodo di input di rsyslogd per farlo.