Comment trouver la raison du redémarrage de Linux ?

Il arrive fréquemment que l'on constate qu'un système Linux a effectué un redémarrage inattendu, souvent sans raison apparente. Identifier la cause de ces redémarrages permet de prévenir leur réapparition et d'éviter des interruptions de service non planifiées.

Plusieurs méthodes existent pour déterminer l'origine d'un redémarrage. Cet article explore ces approches et montre comment utiliser les outils et les fichiers de log disponibles dans un système Linux pour analyser de telles situations.

Analyse du moment du redémarrage

Il est possible de vérifier quand un redémarrage système a eu lieu en utilisant les commandes who et last.


$ who -b
system boot 2021-02-13 20:51

$ last -x | head | tac
abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in
$

Examen des messages système

Il est également possible de relier un redémarrage au moment précis où les messages du système ont été générés.

Pour les distributions CentOS/RHEL, les logs se trouvent généralement dans /var/log/messages. Sur les systèmes Ubuntu/Debian, ils sont enregistrés dans /var/log/syslog. L'utilisation de la commande tail ou d'un éditeur de texte permet de filtrer et de rechercher des informations pertinentes.

Comme les extraits de logs ci-dessous le montrent, ces entrées suggèrent un arrêt/redémarrage initié par un administrateur ou un utilisateur root. Ces messages peuvent différer selon le système d'exploitation et la méthode utilisée pour déclencher le redémarrage, mais les logs système contiennent toujours des informations utiles, même si elles ne révèlent pas toujours clairement la cause première du problème.


Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5
Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root.
Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root.
Feb 13 20:04:09 centos7vm systemd-logind: System is powering down.
Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket.
Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.

Voici une commande que vous pouvez utiliser pour filtrer les logs système afin d'identifier des éléments pertinents :

sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel'
/var/log/messages /var/log/syslog /var/log/apcupsd*
| grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'

Les informations collectées ne sont pas toujours très précises. Il est crucial d'analyser tous les événements qui pourraient signaler des avertissements ou des erreurs menant à l'arrêt ou au blocage du système.

Consultation des logs auditd

Pour les systèmes utilisant auditd, c'est un emplacement précieux pour étudier différents événements en utilisant l'outil ausearch. La commande ci-dessous permet d'examiner les deux dernières entrées des logs d'audit.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

Cette commande affiche les deux derniers arrêts ou redémarrages. Si l'on observe un SYSTEM_SHUTDOWN suivi d'un SYSTEM_BOOT, tout est probablement normal. Cependant, si deux lignes SYSTEM_BOOT apparaissent consécutivement ou une seule ligne SYSTEM_BOOT, il est fort probable que le système ne s'est pas arrêté correctement. Une sortie habituelle devrait ressembler à ceci :


$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$

L'exemple ci-dessous montre deux messages SYSTEM_BOOT consécutifs, ce qui peut indiquer un arrêt inattendu, bien qu'il faille corréler cela avec les logs système :


$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$

Analyse du journal systemd

Il est préférable d'avoir un journal systemd persistant pour conserver l'historique des logs sur le disque, car sinon, ils ne seront pas sauvegardés après un redémarrage. Vous pouvez effectuer cette configuration en modifiant /etc/systemd/journald.conf ou en créant le répertoire nécessaire à l'aide des commandes suivantes :


$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald

Une fois cela fait, vous pouvez éventuellement redémarrer le système pour enregistrer plus d'une entrée de redémarrage dans le journal, bien que cela ne soit pas obligatoire.

La commande ci-dessous liste les démarrages enregistrés dans le journal :

$ journalctl --list-boots

Voici un exemple de sortie:


$ journalctl --list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST
 -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST
 -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST
 -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST
 -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST
 -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST
 -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST
 -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST
 -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST
 -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST
  0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
$

Comme on peut le voir, la liste contient plusieurs démarrages. Pour examiner en détail un redémarrage particulier, il faut utiliser :

$ journalctl -b {num} -n

Ici, {num} représente l'index affiché par la commande journalctl --list-boots dans la première colonne.


$ journalctl -b -1 -n
-- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. --
Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped
$

En analysant les messages du journal ci-dessus, vous pouvez rechercher d'éventuelles anomalies.

Conclusion

Il n'est pas toujours facile d'identifier l'origine d'un redémarrage de Linux en utilisant une seule commande ou en consultant un seul fichier de log. C'est pourquoi il est important de connaître les commandes et les fichiers de logs qui enregistrent les événements liés au système, car cela peut réduire le temps nécessaire pour déterminer la cause première d'un problème.

Les exemples précédents fournissent une base solide pour débuter votre diagnostic. En combinant l'utilisation de ces outils et de ces logs, vous aurez plus de chances de comprendre ce qui s'est passé et pourquoi votre système a redémarré.

Ensuite, découvrez des logiciels de surveillance légers pour Linux.