Où sont les messages de log Upstart sur Ubuntu 13.X?

28

Sous Ubuntu 12.04, je peux trouver des messages de 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

Sous Ubuntu 13.10, les messages n'apparaissent pas dans syslog ou ailleurs dans le répertoire /var/log , bien que les commandes comme logger hello fonctionnent comme prévu. Devrais-je les chercher ailleurs? Y a-t-il un paramètre de configuration que je dois changer quelque part?

Il y a un question sur le défaut du serveur de quelqu'un qui semble avoir le même problème sur Ubuntu 13.04, et plus ici et ici . décrivant le même problème. Malheureusement, ces questions n'offrent aucune piste pour le problème.

    
posée Bradd Szonye 01.04.2014 - 04:03
la source

2 réponses

37

Modifier 2016-06-02

Si vous essayez de trouver "Messages de journal de démarrage" en général, vérifiez /var/log/upstart/ . C'est là que Upstart économise stdout et stderr des services Upstart. Merci à Léopd pour sa réponse.

Si vous recherchez des messages de journalisation depuis Upstart lui-même, configurés par initctl log-priority et émis par initctl emit , lisez la suite!

Version courte

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

Si vous les voulez aussi 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 cela est géré par dpkg. Maintenant, les messages Upstart doivent apparaître dans /var/log/syslog , une fois que vous avez défini log-priority à info ou plus.

Version longue

Cela m'a pris des jours pour suivre, mais apparemment, Upstart (1.5) ne pas se connecte à 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 que c'était possible pour les processus d’espace utilisateur d’écrire dans ce tampon, mais apparemment, ils pouvaient écrire dans /dev/kmsg , et c’est exactement ce que fait Upstart. Donc, c'est la première partie du puzzle.

La deuxième partie est qu’il ya une croyance répandue que les messages écrits dans le tampon en 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 fait par un démon d'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 la mémoire tampon du noyau depuis l’espace utilisateur sont en réalité différents des messages écrits depuis l’espace du noyau: ils ont une fonctionnalité différente. dmesg a quelques options qui interagissent avec ceci: -x affichera la fonction (et la priorité), tandis que -u et -k indiquent respectivement à dmesg d'afficher uniquement les messages des fonctions utilisateur et les fonctionnalités du noyau.

Maintenant, voici le clincher: par défaut, rsyslogd ignore les messages avec une fonction autre que le noyau lorsqu'il lit les messages du tampon en 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 en anneau du noyau comme ayant la fonctionnalité kern , quelle que soit la facilité 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écrite dans man 3 syslog . Apparemment, ces fonctions écrivent dans /dev/log . Le code peut lire à partir de syslog en lisant /dev/log , et c'est ce que font syslogd et ses remplacements. rsyslogd lit /dev/log à l'aide de son module d'entrée imuxsock .

Tampon en anneau du noyau

L'espace du noyau écrit dans ce tampon en appelant la fonction du noyau printk() , de sorte qu'il est parfois appelé tampon printk. L'espace utilisateur peut y écrire en écrivant à /dev/kmsg . L'espace utilisateur peut lire ce tampon par plusieurs méthodes: il peut lire /proc/kmsg (ce que dmesg fait par défaut) ou lire /dev/kmsg ou appeler l'appel système syslog() , décrit dans man 2 syslog et complètement différent de la fonction glibc syslog() décrit dans man 3 syslog . En fait, glibc fournit un wrapper à l’appel système syslog() , appelé klogctl() , pour 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 prend pas la peine d'appeler le glibc syslog() , c'est pourquoi il 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 y a l'avertissement supplémentaire que toutes les sorties imklog ont la fonctionnalité kern , indépendamment des messages d'installation présents dans le tampon en anneau du noyau.

Références

  • lien (indique à tort que Upstart se connecte à syslog)
  • lien
  • lien
  • lien (notez que ceci est pour la version 5, utilisée dans Ubuntu 12.04. Ces options sont considérés comme hérités dans les versions récentes de rsyslog)
réponse donnée Matthew Phipps 02.07.2014 - 19:13
la source
15

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

    
réponse donnée Leopd 26.05.2015 - 02:14
la source

Lire d'autres questions sur les étiquettes