Modifier 2016-06-02
Si vous essayez de trouver des "messages de journal Upstart" en général, vérifiez /var/log/upstart/. C'est là que Upstart enregistre stdoutet stderrdes services Upstart. Merci à la réponse de leopd de l'avoir signalé.
Si vous recherchez des messages de journal d'Upstart lui-même, qui sont configurés initctl log-priorityet émis par initctl emit, lisez la suite!
Version courte
Les entrées de journal devraient en fait apparaître dans dmesg. Malgré cela, ils n'apparaissent pas par défaut dans /var/log.
Si vous les voulez /var/logaussi, ajoutez $KLogPermitNonKernelFacility onà la configuration de rsyslogd. Je suggère de créer un fichier personnalisé /etc/rsyslog.d/60-custom.confafin d'éviter toute modification /etc/rsyslog.conf, car il est géré par dpkg. Maintenant, les messages Upstart devraient apparaître dans /var/log/syslog, une fois que vous avez configuré Upstart log-prioritysur infoenviron.
Version longue
Cela m'a pris des jours à rechercher, mais apparemment Upstart (1.5) ne se connecte pas à syslog, c'est-à-dire qu'il n'appelle pas la fonction glibc syslog(). Au lieu de cela, Upstart se connecte au tampon en anneau du noyau, ce que lit dmesg. Maintenant, je ne pensais pas qu'il était possible pour les processus de l'espace utilisateur d'écrire dans ce tampon, mais apparemment ils peuvent le faire 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 d'anneau 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 effectué par un démon de l'espace utilisateur, traditionnellement klogd, qui fonctionne en tandem avec syslogd. Évidemment, rsyslogd remplace syslogd mais apparemment il remplace également klogd (sorte de: 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 du noyau: ils ont une fonctionnalité différente. dmesg a quelques options qui interagissent avec cela: -xaffichera la fonction (et la priorité), tandis que -uet -kindiquera à dmesg de n'afficher que les messages de la fonction utilisateur et les messages de la fonction noyau, respectivement.
Maintenant, voici l'essentiel: par défaut, rsyslogd ignore les messages avec une fonction non-noyau lorsqu'il lit des messages à partir du tampon d'anneau du noyau. L'option de configuration appropriée est $KLogPermitNonKernelFacility, qui est désactivée par défaut et doit être activée si vous souhaitez que rsyslogd traite ces messages. Notez que le reste de la configuration de rsyslogd traitera tous les messages du tampon d'anneau du noyau comme ayant la fonction kern, quelle que soit la fonction qu'ils avaient dans le tampon d'anneau du noyau.
Plus d'information
syslog
Le code peut écrire dans syslog en appelant la fonction glibc syslog(), décrite dans man 3 syslog. Apparemment, ces fonctions écrivent /dev/log. Le code peut lire à partir de syslog en lisant /dev/log, et c'est ce syslogdque font ses remplaçants. rsyslogdlit en /dev/logutilisant son imuxsockmodule d'entrée.
Tampon d'anneau de noyau
L'espace du noyau écrit dans ce tampon en appelant la fonction du noyau printk(), il est donc parfois appelé tampon printk. L'espace utilisateur peut y écrire en écrivant à /dev/kmsg. L'espace utilisateur peut lire à partir de ce tampon par plusieurs méthodes: il peut lire /proc/kmsg(ce que fait dmesg par défaut), ou il peut lire /dev/kmsg, ou il peut appeler l'appel système syslog(), qui est décrit dans man 2 sysloget complètement différent de la fonction glibc syslog()décrite dans man 3 syslog. glibc fournit en fait un wrapper à l'appel système syslog(), appelé klogctl(), pour aider à atténuer cette confusion.
Traditionnellement, klogdlit à partir de 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 imklogmodule 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 imklogtout comme il traite la sortie de tout autre module d'entrée. Il y a la mise en garde supplémentaire que toutes les imklogsorties ont la kernfacilité indépendamment des messages de la facilité qu'il y avait dans le tampon d'anneau du noyau.
Les références
dmesgmais cela n'avait aucun sens sans le contexte donné ici.