Sur Ubuntu 12.04, je peux trouver les messages du journal Upstart dans /var/log/syslog .
Commandes :
# initctl log-priority info
# initctl emit hello
Journal :
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
Sur Ubuntu 13.10, les messages n'apparaissent pas dans syslog ou n'importe où ailleurs sous /var/log répertoire, bien que des commandes comme logger hello travailler comme prévu. Dois-je les chercher ailleurs ? Y a-t-il un paramètre de configuration que je dois modifier quelque part ?
Il y a une question sur Server Fault de quelqu'un qui semble avoir le même problème sur Ubuntu 13.04, et plus ici et ici qui peuvent également décrire le même problème. Malheureusement, ces questions n'offrent aucune piste pour résoudre le problème.
Meilleure réponse
Modifier 2016-06-02
Si vous essayez de trouver les "messages du journal Upstart" en général, vérifiez /var/log/upstart/ . C'est là que Upstart enregistre stdout et stderr des services Upstart. Merci à la réponse de leopd pour l'avoir signalé.
Si vous recherchez des messages de journal d'Upstart lui-même, qui sont configurés par initctl log-priority et émis par initctl emit , lisez la suite !
Version courte
Les entrées du journal devraient en fait apparaître dans dmesg. Malgré cela, ils ne le font pas apparaissent par défaut dans /var/log .
Si vous les voulez dans /var/log aussi, ajoutez $KLogPermitNonKernelFacility on à la configuration de rsyslogd. Je suggère de créer un fichier personnalisé comme /etc/rsyslog.d/60-custom.conf pour éviter de modifier /etc/rsyslog.conf , puisque c'est géré par dpkg. Maintenant, les messages Upstart doivent apparaître dans /var/log/syslog , une fois que vous avez défini la log-priority d'Upstart à info ou alors.
Version longue
Cela m'a pris des jours à retrouver, mais apparemment Upstart (1.5) ne le fait pas log à syslog, c'est-à-dire qu'il n'appelle pas la fonction glibc syslog() . Au lieu de cela, Upstart se connecte au tampon circulaire du noyau, qui est ce que lit dmesg. Maintenant, je ne pensais pas que c'était possible pour que les processus de l'espace utilisateur écrivent dans ce tampon, mais apparemment ils le peuvent en écrivant dans /dev/kmsg , et c'est exactement ce que fait Upstart. Voilà donc la première partie du puzzle.
La deuxième partie est qu'il existe une croyance largement répandue selon laquelle les messages écrits dans le tampon circulaire du noyau sont automatiquement copiés dans syslog par le noyau (du moins c'est ce que j'ai toujours pensé). Il s'avère que cela est en fait fait par un démon de l'espace utilisateur, traditionnellement klogd, qui fonctionne en tandem avec syslogd. De toute évidence, rsyslogd remplace syslogd mais apparemment, il remplace également klogd (en quelque sorte :voir les notes à la fin).
La troisième partie est que les messages écrits dans le tampon en anneau du noyau depuis l'espace utilisateur sont en fait différents des messages écrits depuis l'espace noyau :ils ont une fonction différente. dmesg a quelques options qui interagissent avec ceci :-x affichera l'installation (et la priorité), tandis que -u et -k indiquez à dmesg de n'afficher que les messages d'installation de l'utilisateur et les messages d'installation du noyau, respectivement.
Voici maintenant le point décisif :par défaut, rsyslogd ignore messages avec une fonction non-noyau lorsqu'il lit des messages à partir du tampon en anneau du noyau. L'option de configuration pertinente est $KLogPermitNonKernelFacility , qui est désactivé par défaut et doit être activé si vous souhaitez que rsyslogd traite ces messages. Notez que le reste de la configuration de rsyslogd traitera tous les messages du tampon circulaire du noyau comme ayant le kern installation, quelle que soit l'installation qu'ils avaient dans le tampon en anneau du noyau.
Plus d'informations
syslog
Le code peut écrire dans syslog en appelant la fonction glibc syslog() , décrit dans man 3 syslog . Apparemment, ces fonctions écrivent dans /dev/log . Le code peut lire depuis syslog en lisant /dev/log , et c'est ce que syslogd et ses remplaçants le font. rsyslogd lit /dev/log en utilisant son imuxsock module d'entrée.
Buffer circulaire du noyau
L'espace noyau écrit dans ce tampon en appelant la fonction noyau printk() , il est donc parfois appelé le tampon printk. L'espace utilisateur peut y écrire en écrivant dans /dev/kmsg . L'espace utilisateur peut lire à partir de ce tampon par plusieurs méthodes :il peut lire à partir de /proc/kmsg (ce que fait dmesg par défaut), ou il peut lire depuis /dev/kmsg , ou il peut appeler l'appel système syslog() , qui est décrit dans man 2 syslog et est complètement différent depuis la fonction glibc syslog() décrit dans man 3 syslog . glibc fournit en fait un wrapper à l'appel système syslog() , appelé klogctl() , pour aider à dissiper cette confusion.
Traditionnellement, klogd lit depuis l'une de ces interfaces, puis appelle la fonction glibc syslog() pour les copier dans le syslog. rsyslogd lit l'une de ces interfaces via son imklog module d'entrée mais AFAIK ne prend pas la peine d'appeler la glibc syslog() , c'est pourquoi ce n'est pas exactement comme klogd; il traite simplement la sortie de imklog tout comme il traite la sortie de n'importe quel autre module d'entrée. Il y a la mise en garde supplémentaire que tous les imklog la sortie a le kern service indépendamment des messages de service contenus dans le tampon en anneau du noyau.
Références
- http://upstart.ubuntu.com/cookbook/#initctl-log-priority (indique à tort qu'Upstart se connecte à 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 (Notez qu'il s'agit de la v5, utilisée dans Ubuntu 12.04. Ces options sont considérées comme héritées dans les versions récentes de rsyslog)