Dépannage des services Linux systemd avec systemctl et journalctl : guide pratique

Introduction

Quand un service Linux systemd se comporte mal, la meilleure réponse est une méthode reproductible. Ce guide montre comment utiliser systemctl et journalctl pour trouver les failed services, lire des logs précis, valider la configuration des systemd unit files et redémarrer en limitant l'impact en environnement proche de la production. Vous y trouverez des commandes prêtes à copier, des conseils concrets et un petit plan pilote pour tester localement avant une généralisation.

Vue d'ensemble du flux

Un flux sûr et orienté production :

1. Identifier quelles unités sont en mauvaise santé.
2. Lire des logs détaillés pour le contexte et la chronologie.
3. Valider le unit file et les overrides.
4. Appliquer la correction minimale viable.
5. Recharger et redémarrer avec des garde-fous.
6. Confirmer l'état de santé et surveiller les logs.
7. Documenter les constats et les prochaines actions.

Inspecter l'état avec systemctl

Commencez par un scan rapide de santé.

• Lister les services en échec :

  systemctl --failed --type=service

• Voir toutes les unités de type service (tous états) :

  systemctl list-units --type=service --all

• Examiner un service précis :

  systemctl status myapp.service --no-pager -l

La sortie de status montre l'état actif, des logs récents et le PID principal.

Pour les dépendances et l'ordonnancement :

• Afficher l'arborescence de dépendances :

  systemctl list-dependencies myapp.service

• Voir les relations clés :

  systemctl show -p After -p Wants -p Requires myapp.service

Ces commandes aident à comprendre pourquoi un démarrage échoue (ex. un autre service requis est down) et à repérer les unités critiques liées.

Lire les logs avec journalctl

Utilisez journalctl pour obtenir des détails d'erreurs alignés sur le temps et le boot.

Modèles courants :

• Suivre les logs en direct :

  journalctl -fu myapp.service --no-pager

• Contexte complet avec explications et saut à la fin :

  journalctl -xeu myapp.service --no-pager

• Restreindre au boot courant :

  journalctl -u myapp.service -b --no-pager

• Boot précédent pour traquer une régression :

  journalctl -u myapp.service -b -1 --no-pager

• Fenêtre temporelle ciblée :

  journalctl -u myapp.service --since "2024-07-01 10:00" --until "2024-07-01 10:30" --no-pager

Si les logs semblent clairsemés, vérifiez la journalisation persistante. Sur de nombreux systèmes, créer /var/log/journal, définir Storage=persistent dans /etc/systemd/journald.conf, puis redémarrer systemd-journald permet de conserver les logs à travers les redémarrages.

Valider et corriger la configuration

Confirmez ce que systemd utilise réellement :

• Afficher le unit file effectif (incluant les drop-ins) :

  systemctl cat myapp.service

• Trouver le chemin du fragment sur disque :

  systemctl show -p FragmentPath myapp.service

• Vérifier la syntaxe :

  systemd-analyze verify /etc/systemd/system/myapp.service

Points d'attention fréquents :

• Chemin ou arguments ExecStart incorrects.
• EnvironmentFile manquant ou variables absentes.
• Permissions du binaire ou du répertoire de travail insuffisantes.
• User= ou Group= sans accès aux fichiers, sockets ou ports requis.
• Réglages Restart= déclenchant des boucles de crash trop rapides.

Privilégiez des changements minimaux et traçables avec un drop-in :

systemctl edit myapp.service

Cela ouvre un fichier d'override du type /etc/systemd/system/myapp.service.d/override.conf.

Exemple pour ajouter un fichier d'environnement et ralentir les redémarrages :

[Service]
EnvironmentFile=/etc/myapp/myapp.env
Restart=on-failure
RestartSec=5s

Après l'édition :

systemctl daemon-reload

Appliquez ensuite la correction la plus petite possible (ex. corriger un chemin, ajuster une permission) et re-testez avant tout changement plus large.

Redémarrer et récupérer en sécurité

Choisissez l'action la moins perturbatrice en premier :

• Si supporté, recharger la config sans redémarrage complet :

  systemctl reload myapp.service

• Si le reload n'existe pas ou ne suffit pas, redémarrer :

  systemctl restart myapp.service

Garde-fous utiles :

• Redémarrer uniquement si déjà actif (évite un démarrage inattendu) :

  systemctl try-restart myapp.service

• Effacer les compteurs d'échec avant une nouvelle tentative après backoff :

  systemctl reset-failed myapp.service

Gérer l'activation :

• Vérifier l'activation :

  systemctl is-enabled myapp.service

• Activer au boot (sans démarrer maintenant) :

  systemctl enable myapp.service

• Activer et démarrer immédiatement :

  systemctl enable --now myapp.service

• Désactiver proprement :

  systemctl disable myapp.service

Bloquer les démarrages accidentels d'unités cassées :

systemctl mask myapp.service
# plus tard
systemctl unmask myapp.service

Valider la récupération :

• Confirmer l'état :

  systemctl is-active myapp.service

• Vérifier les ports d'écoute si pertinent :

  ss -lntp | grep myapp

• Surveiller les logs après redémarrage :

  journalctl -fu myapp.service --no-pager

Plan pilote local

Démarrez avec un pilote restreint et mesurable pour inspecter les résultats localement avant une adoption plus large.

Objectif du pilote : prouver que vous pouvez identifier, diagnostiquer et corriger un service en échec de manière sûre.

Périmètre et étapes :

1. Choisir un service à faible risque (ou un service de test) sur un hôte non critique.
2. Capturer une base : systemctl status, les 200 dernières lignes de logs et le contenu du unit file.
3. Appliquer un changement minimal (ex. corriger un chemin d'EnvironmentFile via un drop-in).
4. Exécuter systemctl daemon-reload, puis try-restart ou reload.
5. Valider : is-active retourne active, les logs ne montrent pas de nouvelles erreurs pendant 10 minutes, et le service remplit sa fonction principale.
6. Documenter les commandes exactes et les résultats pour rendre l'approche réutilisable.

Critères de succès :

• Erreur mesurable résolue.
• Aucun impact collatéral sur d'autres services.
• Chemin de retour confirmé (supprimer le drop-in, daemon-reload, restart).

Extension facultative (systemd timers) :

• Inspecter les timers et leurs plannings :

  systemctl list-timers --all
  journalctl -u myjob.timer --no-pager

Vérifiez aussi le service associé au timer et validez ses logs et son statut comme ci-dessus.

Conclusion

Un flux cohérent basé sur systemctl et journalctl réduit le temps de rétablissement : trouver rapidement les pannes, obtenir des logs précis, valider les définitions d'unités et redémarrer avec des garde-fous. Commencez par un petit pilote local, prouvez chaque étape, puis appliquez la même méthode aux services plus sensibles. Gardez des changements minimaux, observables et réversibles pour un dépannage fiable en environnement de type production.