La machine est revenue, mais journalctl ne montre que le démarrage en cours. Sur ce serveur, le journal n’est pas persistant (Storage=auto sans répertoire /var/log/journal). Les traces du démarrage précédent sont donc perdues de ce côté-là. Heureusement, d’autres sources survivent à un redémarrage.

Source 1 : rsyslog et /var/log/messages

grep -E "System is rebooting|Command line:" /var/log/messages | tail -4
# 19:49:42 systemd-logind: System is rebooting.
# 20:20:22 kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-211.67.1…

Le journal s’arrête net à « System is rebooting », puis reprend trente minutes plus tard avec la ligne de commande du nouveau noyau. Ce silence n’est pas suspect : rsyslog fait partie des premiers services arrêtés pendant un reboot, il n’écrit donc jamais la fin de la séquence d’arrêt. Il faut chercher la suite ailleurs.

Source 2 : wtmp, le registre des connexions et des arrêts

last -x -F | head -6
# reboot   system boot  6.12.0-211.67.1  Wed Oct 21 20:20:26 2026   still running
# shutdown system down  6.12.0-211.54.1  Wed Oct 21 19:50:04 2026 - 20:20:26 (00:30)

last -x affiche aussi les entrées système, pas seulement les connexions. La ligne shutdown system down est écrite par systemd-update-utmp à la toute fin de la séquence d’arrêt, quand presque tous les services sont déjà arrêtés. Sa présence prouve que systemd est allé au bout. Elle est horodatée à 19:50:04, soit 22 secondes après le début du reboot. La colonne « (00:30) » est la durée jusqu’au démarrage suivant : trente minutes pendant lesquelles la machine n’a rien fait.

Source 3 : le montage des systèmes de fichiers au démarrage suivant

grep -E "XFS .*(Mounting|recovery|clean mount)" /var/log/messages | grep "20:20"
# XFS (dm-0): Mounting V5 Filesystem …
# XFS (dm-0): Ending clean mount

Quand un système de fichiers XFS n’a pas été démonté proprement, le montage suivant rejoue son journal et affiche « Starting recovery » puis « Ending recovery ». Ici, les quatre systèmes de fichiers indiquent « Ending clean mount » : ils avaient tous été démontés correctement. Le système d’exploitation avait donc terminé son arrêt avant que la machine ne se fige.

Ce que ça permet de conclure

  • l’arrêt systemd est allé au bout (entrée shutdown dans wtmp) ;
  • les disques ont été démontés proprement (montage « clean » ensuite) ;
  • la machine n’a ensuite plus rien fait pendant trente minutes, jusqu’à ce qu’on la relance à la main.

Le blocage s’est donc produit après que le noyau a demandé à la carte mère de redémarrer, quelque part entre cet appel et le BIOS. Ce n’est ni un paquet, ni un service, ni un système de fichiers.

Pour la prochaine fois

Rendre le journal persistant simplifie beaucoup ce genre d’enquête. C’est une ligne :

mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal
journalctl --list-boots      # les démarrages précédents apparaissent désormais

Même persistant, le journal ne verra jamais ce qui se passe après l’arrêt du noyau. Les indices de wtmp et des montages restent les plus fiables pour savoir si un arrêt s’est terminé proprement.

Ce billet fait partie d’une série de notes d’administration système (tag « carnet d’admin »).
Série « Le serveur qui ne revenait pas », partie 2/3. · ← Billet précédent · Billet suivant → (à paraître le 27/10) · English version