web-dev-qa-db-fra.com

Beaucoup plus détaillé / var / log / *

Je me souviens du temps où littéralement chaque message de journal était probablement mis dans /var/log/messages et /var/log/syslog. C'était l'année 2000 si quelqu'un est curieux. Maintenant c'est différent. Les fichiers journaux sont censés être en ordre, mais au lieu de cela, ils ne disposent que d'entrées. Dans ma perception, 90% des situations problématiques sont silencieuses, impossible de trouver quoi que ce soit dans les fichiers /var/log.

Comment récupérer /var/log/messages et le rendre réellement verbeux?

PS. À titre d'exemple. Quand j'installe vsftpd et que je fais:

Sudo restart vsftpd

alors ce qui va dans syslog est la ligne suivante:

kernel: [ 7167.143648] init: vsftpd main process (5823) killed by TERM signal

C'est le seul effet du redémarrage d'un serveur FTP. Pensez-y: est-il possible que vsftpd ne génère aucune bannière au démarrage? C'est difficile à croire pour moi.

En outre, le journal vient de kernel, c’est dmesg qui le détecte. C'est ridicule. Si le noyau n'attrape pas le signal TERM, il ne restera aucune trace dans les journaux concernant redémarrage de démon FTP. C'est le cas lorsque proftpd est redémarré via /etc/init.d/proftpd. Aucune trace dans les journaux, à l'exception de /var/log/proftpd/proftpd.log qui est le propre fichier journal de proftpd configuré par l'option SystemLog.

PS2: J'attache les résultats de Virtual Linux, probablement le premier CD live créé, basé sur Mandrake, à partir de l'année 2001 (noyau 2.4.3-20mdk). Le redémarrage de proftpd donne ici (dans /var/log/messages):

proftpd[2699]: ProFTPD killed (signal 15)
proftpd[2699]: ProFTPD 1.2.2rc1 standalone mode SHUTDOWN
proftpd: proftpd shutdown succeeded
proftpd[2730]: ProFTPD 1.2.2rc1 (release) (built Sun Apr 8 09:53:35 CEST 2001) standalone mode STARTUP
proftpd: proftpd startup succeeded

Le 14.04, syslog est vide et la suivante est connectée à proftpd.log.

proftpd[1326] asus-1201N: ProFTPD killed (signal 15)
proftpd[1326] asus-1201N: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
proftpd[2620] asus-1201N: ProFTPD 1.3.5rc3 (devel) (built Fri Dec 20 2013 18:04:47 UTC) standalone mode STARTUP

Sur VLinux, les éléments suivants sont connectés à messages lorsque sshd est redémarré:

sshd[2821]: Received signal 15; terminating
sshd: sshd shutdown succeeded
sshd[2924]: Server listening on 0.0.0.0 port 22.
sshd[2924]: Generating 768 bit RSA key.
sshd: sshd startup succeeded
sshd[2924]: RSA key generation complete

Le 14.04, syslog est vide et la suivante est connectée à auth.log (pourquoi?):

Nov 28 09:11:22 asus-1201N sshd[2500]: Received signal 15; terminating.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on 0.0.0.0 port 22.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on :: port 22.

Donc, fondamentalement, deux lignes sans compter la troisième ligne IPv6. J'ai ensuite introduit une erreur dans sshd_config et répété les redémarrages. VLinux/messages:

sshd[2924]: Received signal 15; terminating.
sshd: sshd shutdown succeeded
sshd: sshd startup failed

Le 14.04, auth.log est vide et syslog n'est pas:

kernel: [ 2905.854777] init: ssh main process (2718) terminated with status 255
kernel: [ 2905.854836] init: ssh main process ended, respawning

Sur VLinux, un message détaillé concernant une erreur dans le fichier de configuration imprimé dans la console sur laquelle je lance /etc/init.d/sshd restart ("Option de configuration incorrecte: ..."). Je me demande si, lorsque sshd serait lancé par le système, le message serait alors consigné dans messages. Je suppose que oui, mais je ne peux pas tester cela avec un CD live.

Le redémarrage de proftpd avec une erreur dans la configuration enregistre des informations complètes sur VLinux et le 14.04. Il envoie un message d’erreur au terminal lorsque cette opération est effectuée pour la deuxième fois. Aucun autre effet que "SHUTDOWN" n’est enregistré dans proftpd.log (syslog est vide) .

Sommaire:

  • Je ne pouvais pas prouver clairement que messages disposait de plus d'informations, mais on peut peut-être constater que ce qui prévaut actuellement consiste à économiser de l'espace disque (?) Et à ne pas trop enregistrer
  • il faut passer de auth.log, syslog à des journaux dédiés pour trouver des informations. Son contenu est généralement dépourvu de sens, car apparemment, aucune sortie des démons n’est transmise dans les journaux. Au lieu de cela, le noyau récupère "quelque chose" ou propre travail du démon pour gérer son propre fichier journal
  • Je suis à peu près sûr que dans le cas d'une erreur sophistiquée, je trouverais quelque chose dans messages, alors que dans syslog actuel, il y aurait des informations typiques sur le noyau pour mettre fin à un processus; Je pourrais encore avoir une idée d'un tel test pour montrer cela
  • bien que je n’ai pas clairement montré que la journalisation actuelle manque des éléments, j’ai bien montré à quel point la messages
logsdmesg
2
Adam Lisson

C'est certainement un élément où le nouveau systemd excelle - vous obtenez tous les journaux au même endroit.

Je dois admettre cependant que le montant réellement enregistré n’est pas que impressionnant non plus - la raison indiquée par Gsxr1k réside dans le fait que vsftpd se connecte exclusivement à ses propres fichiers sous /var/log/vsftpd/

journalctl -f

indique à systemd de me montrer le journal en continu, donc après

Sudo systemctl restart vsftpd

ou

Sudo service vsftpd restart

Je reçois

Nov 27 22:45:14 nb-re systemd[1]: Stopping vsftpd FTP server...
Nov 27 22:45:14 nb-re systemd[1]: Stopped vsftpd FTP server.
Nov 27 22:45:14 nb-re systemd[1]: Starting vsftpd FTP server...
Nov 27 22:45:14 nb-re systemd[1]: Started vsftpd FTP server.
5
guntbert

Le fichier de configuration de ce qui est consigné où est (au moins sous Ubuntu 14.04 et 15.10) /etc/rsyslog.d/50-default.conf. En regardant cela, tout est consigné dans /var/log/auth.log ou /var/log/syslog. Je pense que le second est encore plus bavard que l'ancien /var/log/messages.

Si vous voulez récupérer l'ancien /var/log/messages, décommentez les lignes suivantes dans /etc/rsyslog.d/50-default.conf (et supprimez éventuellement ,daemon de la troisième ligne):

*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       cron,daemon.none;\
       mail,news.none          -/var/log/messages
3
Gsxr1k