Cours Linux / Trouver la cause d’une panne avec les journaux système

Pour chercher la cause d’une panne Linux dans les journaux, fixez d’abord l’heure du symptôme et le service concerné, puis comparez les messages du même démarrage avec l’état de la machine et un nouvel essai contrôlé. Une ligne marquée « erreur », même la dernière, ne suffit pas à prouver la cause : lisez ce qui la précède et vérifiez la ressource qu’elle désigne.

Ce guide suppose une machine virtuelle Ubuntu 26.04 LTS ou Rocky Linux 9 équipée de systemd et d’un accès de lecture aux journaux. Les noms de services, la conservation et les permissions de lecture peuvent différer dans un conteneur, WSL ou une autre distribution. Préparez la console et l’environnement de pratique ; le cours sur l’état des services systemd explique les indicateurs de base utilisés ici.

Décrire le symptôme, l’heure et le dernier changement

Écrivez une observation vérifiable, par exemple « depuis 14 h 03, le client A reçoit une réponse HTTP 502 », plutôt que « le serveur ne marche pas ». Notez le dernier essai réussi, les déploiements, modifications de configuration et redémarrages intervenus autour de cette heure. Comparez l’heure et le fuseau du client à ceux du serveur : deux horloges décalées conduisent facilement à examiner le mauvais intervalle. Séparez dans vos notes les faits observés des hypothèses.

date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-boots

journalctl --list-boots indique les démarrages dont le journal possède des entrées. Si le précédent n’apparaît pas, les données peuvent n’avoir jamais été enregistrées durablement, avoir été supprimées selon la politique de conservation ou ne pas être visibles avec vos droits actuels. L’absence d’entrées ne démontre donc pas l’absence de panne. Les paramètres Storage= et les limites de taille sont décrits dans le manuel officiel de journald.conf. Ne changez pas cette configuration pendant la collecte sans en mesurer l’effet.

Filtrer le journal par service, démarrage et intervalle

Remplacez NAME.service par l’unité en cause, après avoir vérifié son nom. Commencez par l’état du service et les messages du démarrage actuel dans un intervalle proche de la panne. Comparez ensuite les avertissements du système et les messages du noyau au même moment :

systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since '30 minutes ago' --no-pager
journalctl -b -p warning --since '30 minutes ago' --no-pager
journalctl -k -b --since '30 minutes ago' --no-pager

-u sélectionne une unité, -b le démarrage courant et -k les messages du noyau. -p warning montre la priorité « warning » et les priorités plus graves ; il peut cependant masquer un message utile émis à la priorité ordinaire ou par la sortie standard de l’application. Après avoir repéré un intervalle, relisez le journal de l’unité sans filtre de priorité et quelques minutes avant le premier échec. Le manuel officiel de journalctl décrit précisément les sélecteurs et leurs combinaisons.

Si l’échec concerne un démarrage antérieur, choisissez son identifiant dans journalctl --list-boots et remplacez le filtre du démarrage courant par ce démarrage précis. Ajustez les heures de début et de fin à votre incident réel. Si un service n’écrit pas dans le journal ou si les droits en masquent des entrées, consultez sa configuration et utilisez le compte autorisé ; ne concluez pas trop tôt qu’aucun message n’existe.

Créer un repère identifiable avec logger

Sur une VM de pratique où logger et la collecte syslog/journal sont présents, l’exemple suivant ajoute deux messages bénins sous un tag propre à l’utilisateur. Il ne modifie aucun service. Le second message simule un avertissement ; ce n’est pas une panne réelle :

tag="linux-course-log-$(id -u)"
logger -t "$tag" 'stage=start case=practice'
logger -p user.warning -t "$tag" 'stage=check result=sample-warning'
journalctl -t "$tag" --since '5 minutes ago' --no-pager

Relevez les deux messages et leur horodatage. Reprenez la dernière commande avec -p warning : le message normal devrait être écarté alors que l’avertissement reste visible. Selon le système, le tag peut être présenté avec un identifiant de processus, mais le filtre -t recherche le champ du tag. Le manuel de logger dans le projet util-linux documente -t et -p.

Un conteneur dépourvu de socket syslog, un système sans journald ou des droits insuffisants peuvent empêcher l’affichage attendu. Vérifiez alors le chemin réel des journaux et l’autorisation de lecture ; ne redémarrez pas le collecteur et n’effacez pas les journaux pour « réparer » l’exercice. Les messages d’essai restent soumis à la politique normale de conservation.

Confronter le message à la ressource désignée

Traitez le message comme un indice et formulez un contrôle ciblé. Les mêmes mots peuvent avoir plusieurs causes :

Une erreur d’espace peut viser le volume de données de l’application, distinct de celui qui contient le journal. Une erreur de permission peut venir d’un répertoire parent ou d’une politique SELinux, même si le fichier semble lisible. Vérifiez le chemin et le processus concernés au lieu de masquer le symptôme en exécutant tout comme root ou en appliquant des permissions 777. Pour les problèmes de route et de port, suivez le diagnostic réseau par étapes.

Chercher les fichiers de log et préserver les éléments utiles

Une application peut écrire dans le journal systemd, sous /var/log, dans son propre répertoire ou dans un collecteur distant. Déterminez d’abord la destination dans sa configuration ; ne supposez pas qu’un fichier précis existe. Pour un fichier confirmé, lisez une portion limitée avec tail -n 100 et recherchez une chaîne significative avec grep. Examinez aussi les fichiers tournants et compressés si l’heure de l’incident est plus ancienne. Convertissez ou annotez les fuseaux horaires avant de comparer avec le journal systemd.

journalctl --disk-usage indique l’espace occupé par les fichiers du journal. N’exécutez pas une purge ou un vacuum avant d’avoir conservé les entrées utiles : elle peut faire disparaître l’unique trace disponible. Exportez seulement la période pertinente vers un emplacement à accès limité, selon les règles de votre environnement. Avant de partager un extrait, retirez les jetons, cookies, identifiants personnels et adresses internes qui n’aident pas au diagnostic.

Pour conclure l’enquête, notez la chronologie, la cause appuyée par les observations, la modification appliquée et le résultat d’un nouvel essai dans les mêmes conditions. Si le problème ne se reproduit pas, conservez cette incertitude au lieu de présenter une corrélation temporelle comme une preuve. Les limites de conservation peuvent ensuite être ajustées séparément en fonction du volume, des besoins d’analyse et des règles de confidentialité.