Diagnostiquer un service systemd avant de le redémarrer

Un redémarrage peut remettre le service en route, mais il efface souvent le contexte utile : erreur de configuration, dépendance indisponible, saturation de ressources ou échec de connexion. Commence par observer l’état et les derniers messages associés à l’unité.

systemctl status myapp.service --no-pager
journalctl -u myapp.service -n 200 --no-pager

Remplace myapp.service par le nom réel de l’unité, par exemple nginx.service, docker.service ou le service applicatif déployé. systemctl status donne le statut et les derniers indices ; journalctl -u fournit le contexte chronologique.

Méthode journalctl pour debug systemd en production

1. Identifier l’état et l’heure du basculement

Observe si l’unité est failed, redémarre en boucle ou reste inactive. Note l’heure du premier échec et le code de sortie affiché. Cette information sert de point de départ pour borner les journaux et recouper avec une alerte ou un déploiement.

systemctl status myapp.service --no-pager
systemctl show myapp.service -p ActiveState -p SubState -p ExecMainStatus

2. Réduire la fenêtre temporelle

Une fenêtre courte réduit le bruit et rend la séquence lisible. Utilise une période légèrement antérieure à l’alerte : le déclencheur précède parfois de quelques minutes le moment où la supervision détecte l’incident.

journalctl -u myapp.service \
  --since "2026-09-11 14:00:00" \
  --until "2026-09-11 14:30:00" \
  --no-pager

Pour un incident récent, une durée relative est souvent plus rapide à utiliser. Le formatage short-precise aide à corréler plusieurs services quand quelques secondes comptent.

journalctl -u myapp.service --since "30 minutes ago" \
  -o short-precise --no-pager

3. Isoler les erreurs sans perdre les messages voisins

Le filtre de priorité fait ressortir les erreurs, mais ne doit pas devenir la seule source de vérité. Une erreur d’authentification ou de configuration peut être annoncée auparavant avec un niveau moins sévère. Lis toujours quelques lignes avant et après le message important.

journalctl -u myapp.service -p err..alert \
  --since "30 minutes ago" --no-pager

journalctl -u myapp.service --since "30 minutes ago" \
  --no-pager | grep -Ei 'error|failed|timeout|denied'

4. Vérifier les dépendances et le démarrage précédent

Un service peut échouer parce que le réseau, le DNS, un montage, une base de données ou un secret n’est pas disponible. Consulte les dépendances déclarées et, après un redémarrage du serveur, le journal du boot précédent.

systemctl list-dependencies --failed
journalctl -u myapp.service -b -1 --no-pager
journalctl -b -1 -p warning..alert --no-pager

Si le symptôme implique une écoute réseau, corrèle ensuite avec les sockets. Le guide ss + journalctl pour le diagnostic réseau Linux détaille cette vérification sans se limiter aux logs.

5. Corriger, puis confirmer le résultat

Applique d’abord le correctif dans un environnement de test ou de staging quand il est disponible. En production, documente le changement, exécute l’action prévue et vérifie à la fois l’état systemd, les nouvelles entrées de journal et le contrôle fonctionnel de l’application.

# Après le correctif validé selon votre procédure de changement
sudo systemctl restart myapp.service
systemctl is-active myapp.service
journalctl -u myapp.service --since "5 minutes ago" --no-pager

• Le service est active et ne redémarre pas en boucle.
• Aucune nouvelle erreur n’apparaît dans la fenêtre qui suit l’action.
• La sonde de supervision et un test fonctionnel confirment le retour au service.

Cas pratique : diagnostiquer un service web qui ne démarre plus

Supposons qu’une alerte indique que Nginx est indisponible après une modification de certificat ou de virtual host. Le premier réflexe utile est de contrôler le statut, puis de lire uniquement le journal de Nginx autour de l’heure du déploiement.

systemctl status nginx.service --no-pager
journalctl -u nginx.service --since "15 minutes ago" --no-pager
nginx -t

Si nginx -t signale une erreur de syntaxe ou un fichier de certificat introuvable, tu disposes d’une cause actionnable. Corrige la configuration dans le dépôt ou le mécanisme de déploiement prévu, valide à nouveau la syntaxe, puis redémarre selon la procédure de changement.

Ne conclus pas trop vite à un défaut Nginx si le journal mentionne une dépendance externe. Une résolution DNS, un port déjà occupé ou un montage absent peut expliquer le même échec. La corrélation avec les événements système évite une correction superficielle.

Interpréter les messages sans s’arrêter au premier échec

Un même incident produit souvent plusieurs messages. L’erreur finale indique ce que systemd constate, alors que la cause se trouve parfois dans un message antérieur : un fichier manquant, une variable non chargée, une permission refusée ou une connexion qui expire. Cherche la première anomalie de la séquence.

Les redémarrages répétés méritent une attention particulière. Systemd applique des limites afin d’éviter une boucle infinie. Le statut peut alors indiquer qu’il a arrêté d’essayer. Vérifie la fréquence des tentatives et les paramètres de redémarrage avant de modifier quoi que ce soit.

systemctl show myapp.service \
  -p Restart -p RestartUSec -p StartLimitBurst -p StartLimitIntervalUSec
journalctl -u myapp.service --since "1 hour ago" -o short-precise --no-pager

Dans un environnement distribué, aligne toujours les horloges avant de conclure à une causalité. Compare les timestamps de l’application, du proxy, de la base de données et de la supervision. Si les fuseaux ou la synchronisation NTP divergent, la fenêtre d’analyse sera trompeuse.

Classe ensuite l’événement dans le runbook : configuration, dépendance, capacité, réseau, certificat ou défaut applicatif. Ce classement ne remplace pas l’analyse de cause racine, mais il rend l’escalade plus précise. L’équipe suivante reçoit des faits, les commandes exécutées et les résultats observés.

Conserver des journaux utiles pour le prochain incident

Un bon diagnostic dépend de journaux encore disponibles. Vérifie d’abord l’espace utilisé et la persistance après redémarrage. Sur certains systèmes, le journal reste volatile tant que la configuration de systemd-journald ne demande pas de stockage persistant.

journalctl --disk-usage
journalctl --list-boots
test -d /var/log/journal && echo "journal persistant présent"

Le dimensionnement de la rétention doit suivre les contraintes de capacité, de sécurité et de conformité. Avant de modifier journald.conf, mesure l’usage actuel, teste la politique sur un environnement non critique et prévois un retour arrière documenté. La centralisation des journaux complète ce dispositif lorsque plusieurs hôtes sont concernés.

Pour passer du diagnostic ponctuel à des alertes exploitables, consulte aussi notre méthode de monitoring serveur avec des alertes utiles. Elle aide à relier symptômes, seuils et procédure d’intervention.

Les erreurs à éviter pendant le diagnostic

FAQ : journalctl et services systemd

Réduire le temps de diagnostic, pas seulement relancer le service

La valeur de journalctl vient d’une méthode répétable : unité, fenêtre temporelle, dépendances, correction et preuve de rétablissement. Documentée dans un runbook, cette séquence réduit les gestes à l’aveugle et accélère l’analyse du prochain incident.

Références : documentation officielle journalctl et documentation officielle systemctl.

Conserve enfin les extraits utiles avec leur fuseau horaire et le nom exact de l’unité. Cette discipline rend la transmission entre équipes plus fiable et évite de rejouer une investigation déjà menée lors de l’incident suivant.