Su Ubuntu 12.04, posso trovare i messaggi di registro di Upstart in /var/log/syslog .
Comandi:
# initctl log-priority info
# initctl emit hello
Registro:
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
Su Ubuntu 13.10, i messaggi non vengono visualizzati in syslog o in qualsiasi altro punto sotto /var/log directory, sebbene comandi come logger hello lavorare come previsto. Dovrei cercarli da qualche altra parte? C'è un'impostazione di configurazione che devo modificare da qualche parte?
C'è una domanda su Server Fault da qualcuno che sembra avere lo stesso problema su Ubuntu 13.04 e altro qui e qui che potrebbe anche descrivere lo stesso problema. Sfortunatamente, queste domande non offrono indizi per il problema.
Migliore risposta
Modifica 02-06-2016
Se stai cercando di trovare "Messaggi di registro di Upstart" in generale, controlla /var/log/upstart/ . È qui che Upstart salva stdout e stderr dai servizi Upstart. Grazie alla risposta di leopd per averlo sottolineato.
Se stai cercando messaggi di registro da Upstart stesso, che sono configurati da initctl log-priority ed emesso da initctl emit , continua a leggere!
Versione breve
Le voci di registro dovrebbero effettivamente essere visualizzate in dmesg. Nonostante ciò, non viene visualizzato per impostazione predefinita in /var/log .
Se li vuoi in /var/log aggiungi anche $KLogPermitNonKernelFacility on alla configurazione di rsyslogd. Suggerisco di creare un file personalizzato come /etc/rsyslog.d/60-custom.conf per evitare di modificare /etc/rsyslog.conf , poiché è gestito da dpkg. Ora i messaggi di Upstart dovrebbero essere visualizzati in /var/log/syslog , dopo aver impostato la log-priority di Upstart a info o giù di lì.
Versione lunga
Mi ci sono voluti giorni per rintracciarlo, ma a quanto pare Upstart (1.5) non log in syslog, cioè non chiama la funzione glibc syslog() . Invece, Upstart registra nel buffer dell'anello del kernel, che è ciò che legge dmesg. Ora, non pensavo fosse possibile affinché i processi dello spazio utente scrivano su quel buffer, ma a quanto pare possono scrivendo su /dev/kmsg , ed è esattamente ciò che fa Upstart. Quindi questa è la prima parte del puzzle.
La seconda parte è che c'è una convinzione diffusa che i messaggi scritti nel buffer dell'anello del kernel vengano automaticamente copiati in syslog dal kernel (almeno questo è quello che ho sempre pensato). Si scopre che questo è effettivamente fatto da un demone dello spazio utente, tradizionalmente klogd, che opera in tandem con syslogd. Ovviamente rsyslogd sostituisce syslogd ma apparentemente sostituisce anche klogd (più o meno:vedi le note alla fine).
La terza parte è che i messaggi scritti nel buffer circolare del kernel dallo spazio utente in realtà hanno un aspetto diverso dai messaggi scritti dallo spazio del kernel:hanno una struttura diversa. dmesg ha alcune opzioni che interagiscono con questo:-x mostrerà la struttura (e la priorità), mentre -u e -k dite a dmesg di mostrare solo i messaggi delle strutture utente e quelli delle strutture del kernel, rispettivamente.
Ora ecco il fattore decisivo:per impostazione predefinita, rsyslogd ignora messaggi con una funzione non del kernel quando legge i messaggi dal buffer dell'anello del kernel. L'opzione di configurazione pertinente è $KLogPermitNonKernelFacility , che è disattivato per impostazione predefinita e deve essere attivato se si desidera che rsyslogd elabori questi messaggi. Nota che il resto della configurazione di rsyslogd tratterà tutti i messaggi dal buffer circolare del kernel come se avessero il kern struttura, indipendentemente dalla struttura che avevano nel buffer dell'anello del kernel.
Maggiori informazioni
syslog
Il codice può scrivere su syslog chiamando la funzione glibc syslog() , descritto in man 3 syslog . Apparentemente queste funzioni scrivono in /dev/log . Il codice può essere letto da syslog leggendo /dev/log , e questo è ciò che syslogd e le sue sostituzioni lo fanno. rsyslogd legge /dev/log usando il suo imuxsock modulo di ingresso.
Buffer dell'anello del kernel
Lo spazio del kernel scrive in questo buffer chiamando la funzione del kernel printk() , quindi a volte viene chiamato printk buffer. Lo spazio utente può scrivervi scrivendo su /dev/kmsg . Lo spazio utente può leggere da questo buffer in diversi metodi:può leggere da /proc/kmsg (cosa fa dmesg per impostazione predefinita), oppure può leggere da /dev/kmsg oppure può chiamare la chiamata di sistema syslog() , che è descritto in man 2 syslog ed è completamente diverso dalla funzione glibc syslog() descritto in man 3 syslog . glibc fornisce effettivamente un wrapper alla chiamata di sistema syslog() , chiamato klogctl() , per alleviare questa confusione.
Tradizionalmente, klogd legge da una di queste interfacce, quindi chiama la funzione glibc syslog() per copiarli nel syslog. rsyslogd legge una di queste interfacce attraverso il suo imklog modulo di input ma AFAIK non si preoccupa di chiamare glibc syslog() , ecco perché non è esattamente come klogd; elabora semplicemente l'output di imklog proprio come elabora l'output da qualsiasi altro modulo di input. C'è l'avvertenza aggiunta che tutti imklog l'output ha il kern struttura indipendentemente dai messaggi di struttura presenti nel buffer dell'anello del kernel.
Riferimenti
- http://upstart.ubuntu.com/cookbook/#initctl-log-priority (indica erroneamente che Upstart si collega a syslog)
- 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 (Si noti che questo è per v5, utilizzato in Ubuntu 12.04. Queste opzioni sono considerate legacy nelle recenti versioni di rsyslog)