web-dev-qa-db-fra.com

Où sont les messages du journal Upstart sur Ubuntu 13.X?

Sur Ubuntu 12.04, je peux trouver les messages de journal 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 pas dans syslog ni ailleurs dans le répertoire /var/log, bien que des commandes telles que logger hello fonctionnent comme prévu. Devrais-je les chercher ailleurs? Y at-il un paramètre de configuration que je dois changer quelque part?

Il y a un 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 peut aussi être décrivant le même problème. Malheureusement, ces questions n'offrent aucune piste au problème.

13.10upstartloggingsyslog
28
Bradd Szonye

Edit 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 stdout et stderr à partir des services Upstart. Merci à la réponse de leopd pour l'avoir signalé.

Si vous recherchez des messages de journal provenant d'Upstart lui-même, qui sont configurés par initctl log-priority et émis par initctl emit, poursuivez votre lecture!

Version courte

Les entrées du journal devraient en fait apparaître dans dmesg. Malgré cela, ils ne s'affichent pas par défaut dans /var/log.

Si vous les voulez également dans /var/log, ajoutez $KLogPermitNonKernelFacility on à la configuration de rsyslogd. Je suggère de créer un fichier personnalisé tel que /etc/rsyslog.d/60-custom.conf pour éviter de modifier /etc/rsyslog.conf, car il est géré par dpkg. Les messages Upstart doivent maintenant apparaître dans /var/log/syslog, une fois que vous avez défini le log-priority de Upstart sur info ou plus.

Version longue

Cela m'a pris des jours pour localiser, mais apparemment Upstart (1.5) ne ne se connecte pas au syslog, c’est-à-dire qu’elle n’appelle pas la fonction glibc syslog(). Au lieu de cela, Upstart se connecte au tampon circulaire du noyau, qui est lu par dmesg. Maintenant, je ne pensais pas qu'il était possible pour les processus d'espace utilisateur d'écrire 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 répandue selon laquelle les messages écrits dans la mémoire 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 effectué par un démon de l'espace utilisateur, traditionnellement klogd, qui fonctionne en tandem avec syslogd. Evidemment, 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 la mémoire tampon du noyau à partir de l'espace utilisateur ont en réalité une apparence différente de ceux qui sont écrits à partir de l'espace noyau: ils ont une installation différente. dmesg a quelques options qui interagissent avec ceci: -x affichera le service (et la priorité), alors que -u et -k diront à dmesg de n’afficher que les messages d’utilisateur et de noyau, respectivement.

Maintenant voici le clincher: par défaut, rsyslogd ignore les messages avec une installation non-noyau lorsqu’il lit les messages à partir de la mémoire tampon circulaire 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 voulez que rsyslogd traite ces messages. Notez que le reste de la configuration de rsyslogd traitera tous les messages du tampon de sonnerie du noyau comme dotés de la fonction kern, quelle que soit la fonction utilisée dans la mémoire tampon 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 dans /dev/log. Le code peut être lu à partir de syslog en lisant /dev/log, et c'est ce que syslogd et ses remplacements font. rsyslogd lit /dev/log en utilisant son module d'entrée imuxsock.

Anneau tampon de noyau

L'espace du noyau écrit dans ce tampon en appelant la fonction du noyau printk(); il est donc parfois appelé le tampon printk. L'espace utilisateur peut y écrire en écrivant à /dev/kmsg. L’espace utilisateur peut lire ce tampon de plusieurs façons: il peut lire /proc/kmsg (ce que dmesg fait par défaut), il peut lire /dev/kmsg ou appeler l’appel système syslog(), décrit dans man 2 syslog et qui est complètement différent de la fonction glibc syslog() décrite dans man 3 syslog. En fait, la glibc fournit un wrapper à l'appel système syslog(), appelé klogctl(), pour aider à atténuer cette confusion.

Traditionnellement, klogd lit 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 module d'entrée imklog mais AFAIK ne se donne pas la peine d'appeler la glibc syslog(), ce qui explique pourquoi ce n'est pas exactement comme klogd; il traite simplement la sortie de imklog, tout comme il traite la sortie de tout autre module d'entrée. Il est à noter que toutes les sorties de imklog ont la possibilité kern, quels que soient les messages de cette fonction contenus dans la mémoire tampon du noyau.

Références

39
Vanessa Phipps

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

16
Leopd