Sur Ubuntu 12.04, je peux trouver des messages de journal d'Upstart dans /var/log/syslog.

Commandes:

# initctl log-priority info
# initctl emit hello

Bûche:

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 ni dans syslogni ailleurs dans le /var/logrépertoire, bien que les commandes comme logger hellofonctionnent comme prévu. Dois-je les chercher ailleurs? Existe-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 le problème.

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

• http://upstart.ubuntu.com/cookbook/#initctl-log-priority (indique à tort que 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 que c'est pour 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)

J'ai trouvé le mien dans /var/log/upstart/