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

Introduction

Lorsqu'un service Linux se comporte mal, la correction la plus rapide provient d'une approche reproductible. Ce guide montre comment utiliser systemctl et journalctl pour repérer les services en échec, lire des journaux précis, valider la configuration de l'unité et redémarrer en toute sécurité. Il se concentre sur des commandes pratiques que vous pouvez copier, ainsi que sur un plan pilote pour tester les modifications localement avant un déploiement plus large.

Aperçu du workflow

Un flux sûr, orienté production :

1. Identifier les unités défaillantes.
2. Lire les journaux détaillés pour le contexte et l'horodatage.
3. Valider le fichier d'unité et les surcharges.
4. Appliquer la correction minimale viable.
5. Recharger et redémarrer avec des garde-fous.
6. Confirmer la santé et surveiller les journaux.
7. Documenter les constats et les prochaines actions.

Inspecter l'état du service avec systemctl

Commencez par un balayage rapide de santé :

• Lister les services en échec :

systemctl --failed --type=service

• Voir tout selon l'état et le type :

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

• Vérifier un service spécifique :

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

La sortie affiche l'état actif, les dernières lignes de journal et le PID principal.

Pour les détails de dépendances et d'ordonnancement :

• Afficher l'arbre de dépendances :

systemctl list-dependencies myapp.service

• Afficher les relations clés (After, Wants, Requires) :

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

Lire les journaux avec journalctl

Utilisez journalctl pour obtenir les détails d'erreur liés au temps et au démarrage.

Motifs courants :

• Suivre les journaux en direct :

journalctl -fu myapp.service --no-pager

• Afficher le contexte complet avec explications et sauter à la dernière entrée :

journalctl -xeu myapp.service --no-pager

• Restreindre au démarrage courant :

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

• Démarrage précédent pour les régressions :

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

• Fenêtre temporelle :

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

• Filtrer par priorité (erreurs seulement) sur la dernière heure :

journalctl -u myapp.service -p err --since "1 hour ago" --no-pager

Si les journaux semblent maigres, assurez-vous que la journalisation persistante est activée. Sur de nombreux systèmes, la création de /var/log/journal et le réglage Storage=persistent dans /etc/systemd/journald.conf, suivis d'un redémarrage de systemd-journald, permettront de conserver les logs après redémarrage.

Valider et corriger la configuration de l'unité

Confirmez ce que systemd utilise réellement :

• Afficher le fichier d'unité 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

Vérifiez les problèmes courants :

• Chemin ou arguments ExecStart incorrects.
• EnvironmentFile ou variables manquantes.
• Permissions sur l'exécutable ou le répertoire de travail.
• User= ou Group= sans droits d'accès aux fichiers ou ports.
• Réglages Restart= provoquant des boucles de crash.

Effectuez des modifications minimales et revues via un drop-in :

systemctl edit myapp.service

Cela ouvre un fichier de surcharge comme /etc/systemd/system/myapp.service.d/override.conf.

Exemple : ajouter un fichier d'environnement et ralentir les redémarrages pour éviter une boucle de crash.

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

Autre exemple concret : corriger un chemin d'exécutable erroné.

[Service]
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.yaml

Après édition :

systemctl daemon-reload

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

Privilégiez l'action la moins perturbatrice en premier :

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

systemctl reload myapp.service

• Sinon, redémarrer :

systemctl restart myapp.service

Garde-fous utiles :

• Redémarrer uniquement si le service est actif (évite de démarrer des services désactivés) :

systemctl try-restart myapp.service

• Réinitialiser les compteurs d'échec avant de réessayer après un backoff :

systemctl reset-failed myapp.service

Activer ou désactiver explicitement :

• Vérifier l'activation :

systemctl is-enabled myapp.service

• Activer au démarrage (ne pas nécessairement 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 pour les unités cassées :

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

Valider la récupération :

• Confirmer l'état actif :

systemctl is-active myapp.service

• Vérifier les ports en écoute si pertinent :

ss -lntp | grep myapp

• Surveiller les journaux après redémarrage :

journalctl -fu myapp.service --no-pager

Plan pilote local

Commencez par un pilote étroit et mesurable afin d'inspecter les résultats localement avant un déploiement plus large.

Objectif du pilote : Prouver que vous pouvez identifier, diagnostiquer et corriger un unique service en échec en toute sécurité.

Périmètre et étapes :

1. Choisir un service à faible risque (ou un service de test) sur un hôte non critique.
2. Capturer la ligne de base : systemctl status, les 200 dernières lignes de journal et le contenu du fichier d'unité.
3. Appliquer une seule modification minimale (par exemple, corriger le chemin d'un EnvironmentFile via un drop-in).
4. systemctl daemon-reload, puis try-restart ou reload.
5. Valider : is-active renvoie active, les journaux n'affichent aucune nouvelle erreur pendant 10 minutes, et le service remplit sa fonction principale.
6. Documenter les commandes exactes et les résultats pour rendre l'approche reproductible.

Critères de succès :

• Erreur mesurée résolue.
• Aucun impact collatéral sur les autres services.
• Chemin de retour confirmé (supprimer le drop-in, daemon-reload, redémarrer).

Extension optionnelle :

• Pour les charges de travail pilotées par des minuteurs, inspecter les minuteurs et les planifications :

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

Vérifier le service associé au minuteur et valider ses journaux et son état comme ci-dessus.

Conclusion

Un flux cohérent utilisant systemctl et journalctl réduit le temps de récupération : détecter les échecs rapidement, obtenir des journaux précis, valider les définitions d'unité et redémarrer avec des garde-fous. Commencez par un petit pilote local, validez chaque étape, puis appliquez la même méthode aux services à plus haut risque. Maintenez les changements minimaux, observables et réversibles.