Logs du dernier démarrage Linux : comment lire journalctl sans se noyer

Après un redémarrage Linux, le piège classique consiste à ouvrir trop de logs à la fois. Vous voyez passer du noyau, des services, du réseau, des tâches systemd, parfois des erreurs anciennes, et au bout de cinq minutes vous ne savez plus ce que vous cherchez.

Dans ce cas, je commence presque toujours par journalctl -b. Cette commande limite la lecture au démarrage courant. C’est simple, mais ça évite déjà de mélanger un problème d’aujourd’hui avec un incident de la veille.

Commencer par les logs du démarrage courant

La commande de base est la suivante :

journalctl -b

Elle affiche les messages du boot actuel, dans l’ordre chronologique. Sur une machine qui vient de redémarrer, c’est souvent le meilleur point de départ pour comprendre pourquoi un service ne s’est pas lancé, pourquoi le réseau est arrivé en retard ou pourquoi un disque a été monté avec une erreur.

Si vous voulez voir les démarrages disponibles, utilisez :

journalctl --list-boots

Vous pouvez ensuite lire le boot précédent avec :

journalctl -b -1

Attention tout de même : sur certaines distributions, les journaux anciens ne sont pas conservés si le journal systemd n’est pas persistant. Si journalctl --list-boots ne montre que le démarrage courant, ce n’est pas forcément une anomalie.

Filtrer les erreurs sans lire tout le journal

Lire tout le flux est rarement utile. Pour un diagnostic rapide, je filtre d’abord les erreurs :

journalctl -b -p err

Pour voir aussi les avertissements, vous pouvez élargir un peu :

journalctl -b -p warning..alert

Ne paniquez pas dès qu’une ligne rouge apparaît. Certains messages sont bruyants sans être bloquants. Ce que je cherche surtout, c’est une erreur répétée, un service qui échoue, un périphérique qui disparaît ou une ligne qui arrive juste avant le symptôme observé.

Si vous préférez un affichage avec des dates plus faciles à relire, ajoutez le format ISO :

journalctl -b -p err -o short-iso

Regarder un service précis

Quand le problème concerne un service précis, inutile de parcourir tout le boot. Par exemple pour SSH :

journalctl -b -u ssh

Selon les distributions, le service peut aussi s’appeler sshd :

journalctl -b -u sshd

Vous pouvez croiser avec systemd pour vérifier l’état réel du service :

systemctl status ssh
systemctl --failed

Si vous modifiez un fichier de service, pensez aussi à relire notre guide sur systemctl daemon-reload. Beaucoup d’erreurs viennent d’une modification correcte sur le disque, mais pas encore rechargée par systemd.

Limiter la période analysée

Sur un serveur bavard, même les logs du boot peuvent être longs. Vous pouvez limiter la recherche à une période :

journalctl -b --since "10 minutes ago"

Ou viser une plage horaire précise :

journalctl -b --since "2026-06-30 08:00" --until "2026-06-30 08:20"

C’est très pratique après un redémarrage planifié. Vous regardez uniquement la fenêtre qui vous intéresse, au lieu de faire défiler des centaines de lignes.

Exporter un extrait propre pour diagnostic

Si vous devez envoyer un extrait à un collègue ou garder une trace avant intervention, évitez de copier toute la sortie. Un export court suffit souvent :

journalctl -b -p err -n 80 --no-pager > boot-errors.log

Pour un service précis :

journalctl -b -u nginx -n 120 --no-pager > nginx-boot.log

Relisez le fichier avant de le partager. Un journal peut contenir des noms de machines, des chemins internes, des adresses IP privées ou des morceaux de configuration.

Si votre diagnostic montre surtout une partition pleine ou des logs qui grossissent trop vite, le problème n’est peut-être pas journalctl lui-même. Dans ce cas, commencez par vérifier l’espace disque avec les commandes de base, comme expliqué dans notre guide sur le disque plein sous Linux.

Ce que je vérifie avant de toucher au service

Avant de redémarrer un service ou de modifier une configuration, je vérifie quatre points :

l’erreur apparaît bien dans le démarrage courant avec journalctl -b ;
le service concerné est identifié avec journalctl -b -u nom-du-service ;
systemctl --failed confirme ou non un vrai échec systemd ;
l’heure de l’erreur correspond au symptôme constaté.

Si ces quatre points ne collent pas, je continue le diagnostic avant de relancer quoi que ce soit. Redémarrer un service au hasard peut masquer le problème, ou pire, couper un accès distant qui fonctionnait encore.

Pour la syntaxe complète, la page du manuel journalctl reste une bonne référence. Mais pour un dépannage terrain, retenez surtout journalctl -b, -p err, -u et --since. Avec ces quatre options, vous couvrez déjà une bonne partie des incidents de démarrage.