Systemd : Utiliser journalctl, les logs de systemd
Table des matières
systemd possède son propre mécanisme de journalisation, syslog n'est plus requis par défaut.
Le paquet rsyslog est toujours installable, mais pourquoi utiliser 2 mêmes outils sur un même système ?
Voici quelques commandes utiles pour se repérer ....
Pour voir les logs :
De manière "tail -f", continue sur la console jusqu'à ctrl+C :
Filtrer par service
Si le 4ème champ n'est pas un service (par exemple les événements sudo), on utilisera -t :
Filtrer par PID :
Filtrer par programme :
Filtrer par niveau de log (ici que les erreurs) :
On peut évidemment combiner toutes ces options :
On peut aussi filtrer les logs par date avec --since et --until. Il faut mettre la date au format YYYY-MM-DD HH:MM:SS
Par exemple depuis 21h le 10/02/2016 :
Ou jusqu'à 22h le 10/02/2016 :
Ou dans cet intervalle en combinant les deux :
On peut parfois utiliser les dates avec des adverbes de temps (exemple depuis hier)
Ou une durée (il y a 10 minutes) :
Il est possible de visualiser les journaux depuis le boot de la machine :
Pour le boot d'avant ajouter -2 :
Et le boot encore d'avant -3 etc ...
On peut imiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier). Pour la fixer à 500 Mo par exemple, on édite le fichier /etc/systemd/journald.conf :
En fixant une limite par fichier, on a un équivalent de logrotate (par défaut, il garde 7 rotations) :
On peut aussi faire en sorte que les journaux ne soient pas conservés sur le disque au redémarrage (machine non critique) :
Si on souhaite envoyer quand même les logs dans /var/log/messages, c'est possible !
Installer rsyslog et démarrer le service.
Ensuite, éditer le fichier /etc/systemd/journald.conf et modifier cette option :
Redémarrer le service systemd-journald pour prendre en compte les modifications
Introduction
systemd possède son propre mécanisme de journalisation, syslog n'est plus requis par défaut.
Le paquet rsyslog est toujours installable, mais pourquoi utiliser 2 mêmes outils sur un même système ?
Voici quelques commandes utiles pour se repérer ....
Visualiser les logs : Utiliser journalctl
Pour voir les logs :
Code BASH :
journalctl
Code :
mai 21 21:24:21 localhost.localdomain systemd[2396]: Startup finished in 1.216s.
mai 21 21:24:21 localhost.localdomain sshd[1695]: pam_tcb(sshd:session): Session opened fo
mai 21 21:24:24 localhost.localdomain su[2452]: pam_tcb(su:auth): Authentication passed fo
mai 21 21:24:24 localhost.localdomain su[2452]: (to root) adrien on pts/0
mai 21 21:24:24 localhost.localdomain su[2452]: pam_tcb(su:session): Session opened for ro
De manière "tail -f", continue sur la console jusqu'à ctrl+C :
Code BASH :
journalctl -fCode :
-- Logs begin at dim. 2015-03-29 22:59:55 CEST. --
mai 21 21:24:21 localhost.localdomain systemd[2396]: Starting Default.
mai 21 21:24:21 localhost.localdomain systemd[2396]: Reached target Default.
mai 21 21:24:21 localhost.localdomain systemd[2396]: Startup finished in 1.216s.
mai 21 21:24:21 localhost.localdomain sshd[1695]: pam_tcb(sshd:session): Session opened fo
Filtrer par service
Code BASH :
journalctl -u crondCode :
mai 21 21:23:43 localhost.localdomain crond[624]: (CRON) INFO (Syslog will be used instead
mai 21 21:23:43 localhost.localdomain crond[624]: (CRON) INFO (RANDOM_DELAY will be scaled
mai 21 21:23:44 localhost.localdomain crond[624]: (CRON) INFO (running with inotify suppor
Si le 4ème champ n'est pas un service (par exemple les événements sudo), on utilisera -t :
Code BASH :
journalctl -t sudo
Code TEXT :
déc. 11 20:53:13 superlinux sudo[18628]: pam_unix(sudo:auth): auth could not identify password f> déc. 11 20:53:23 superlinux sudo[18646]: adrien : TTY=pts/2 ; PWD=/home/adrien ; USER=root ; C> déc. 11 20:53:23 superlinux sudo[18646]: pam_unix(sudo:session): session opened for user root(ui> déc. 11 20:53:28 superlinux sudo[18646]: pam_unix(sudo:session): session closed for user root
Filtrer par PID :
Code BASH :
journalctl _PID=1
Code :
mai 21 21:23:51 localhost.localdomain systemd[1]: lm_sensors.service failed.
mai 21 21:24:03 localhost.localdomain systemd[1]: plymouth-quit-wait.service start operati
mai 21 21:24:03 localhost.localdomain systemd[1]: Failed to start Wait for Plymouth Boot S
mai 21 21:24:03 localhost.localdomain systemd[1]: Unit plymouth-quit-wait.service entered
mai 21 21:24:03 localhost.localdomain systemd[1]: plymouth-quit-wait.service failed.
Filtrer par programme :
Code BASH :
journalctl /usr/sbin/sshd
Code :
mai 21 21:24:06 localhost.localdomain sshd[1268]: Server listening on 0.0.0.0 port 22.
mai 21 21:24:06 localhost.localdomain sshd[1268]: Server listening on :: port 22.
mai 21 21:24:19 localhost.localdomain sshd[1836]: pam_tcb(sshd:auth): Authentication passe
mai 21 21:24:19 localhost.localdomain sshd[1695]: Accepted keyboard-interactive/pam for ad
mai 21 21:24:21 localhost.localdomain sshd[1695]: pam_tcb(sshd:session): Session opened fo
Filtrer par niveau de log (ici que les erreurs) :
Code BASH :
journalctl -p errCode :
mai 21 21:24:06 localhost.localdomain rpcbind[1278]: Cannot open '/var/lib/rpcbind/rpcbind
mai 21 21:24:06 localhost.localdomain rpcbind[1278]: Cannot open '/var/lib/rpcbind/portmap
mai 21 21:24:14 localhost.localdomain kernel: xt_addrtype: ipv6 does not support BROADCAS
On peut évidemment combiner toutes ces options :
Code BASH :
journalctl -f /usr/sbin/urpmi -p info
Code :
-- Logs begin at dim. 2015-03-29 22:59:55 CEST. --
mai 21 21:19:27 localhost.localdomain [RPM][9040]: erase lib64kwinglutils1-2:4.11.16-2.mga5.x86_64: success
mai 21 21:19:28 localhost.localdomain [RPM][9040]: erase lib64kephal4-2:4.11.16-2.mga5.x86_64: success
mai 21 21:19:29 localhost.localdomain [RPM][9040]: erase lib64plasma_applet_system_monitor4-2:4.11.16-2.mga5.x86_64: success
mai 21 21:19:29 localhost.localdomain [RPM][9040]: erase lib64kwineffects1-2:4.11.16-2.mga5.x86_64: success
mai 21 21:19:29 localhost.localdomain [RPM][9040]: erase lib64kwinglesutils1-2:4.11.16-2.mga5.x86_64: success
mai 21 21:19:29 localhost.localdomain [RPM][9040]: Transaction ID 555e2fb9 finished: 0
- - Reboot - -
mai 21 21:34:03 localhost.localdomain urpmi[8355]: called with: hnghggjh
On peut aussi filtrer les logs par date avec --since et --until. Il faut mettre la date au format YYYY-MM-DD HH:MM:SS
Par exemple depuis 21h le 10/02/2016 :
Code BASH :
journalctl --since "2016-02-10 21:00:00"
Ou jusqu'à 22h le 10/02/2016 :
Code BASH :
journalctl --until "2016-02-10 22:00:00"
Ou dans cet intervalle en combinant les deux :
Code BASH :
journalctl --since "2016-02-10 21:00:00" --until "2016-02-10 22:00:00"
On peut parfois utiliser les dates avec des adverbes de temps (exemple depuis hier)
Code BASH :
journalctl --since yesterdayOu une durée (il y a 10 minutes) :
Code BASH :
journalctl --since "10 minutes ago"
Il est possible de visualiser les journaux depuis le boot de la machine :
Code BASH :
journalctl -bPour le boot d'avant ajouter -2 :
Code BASH :
journalctl -b -2
Et le boot encore d'avant -3 etc ...
A propos de la taille
On peut imiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier). Pour la fixer à 500 Mo par exemple, on édite le fichier /etc/systemd/journald.conf :
Code BASH :
SystemMaxUse=500MEn fixant une limite par fichier, on a un équivalent de logrotate (par défaut, il garde 7 rotations) :
Code BASH :
SystemMaxUse=500M SystemMaxFileSize=100M
On peut aussi faire en sorte que les journaux ne soient pas conservés sur le disque au redémarrage (machine non critique) :
Code BASH :
[Journal] Storage=volatile
Envoyer quand même dans /var/log/messages
Si on souhaite envoyer quand même les logs dans /var/log/messages, c'est possible !
Installer rsyslog et démarrer le service.
Ensuite, éditer le fichier /etc/systemd/journald.conf et modifier cette option :
Code BASH :
ForwardToSyslog=yes
Redémarrer le service systemd-journald pour prendre en compte les modifications