Retrouver pourquoi un service systemd est en échec

Un service qui passe en failed n’a pas besoin d’un redémarrage immédiat. Sur un serveur, cette habitude efface parfois le message qui explique la panne, ou relance un programme avec une configuration toujours invalide.

Commencez par identifier l’unité concernée, lisez son état et son journal, puis corrigez la cause. La relance vient après.

Lister les unités réellement en échec

Cette commande affiche les services et unités que systemd considère comme défaillants :

systemctl --failed

Notez le nom complet, par exemple nginx.service ou mon-application.service. Une unité exited n’est pas forcément en panne : certains services exécutent une tâche courte puis s’arrêtent normalement. Le statut failed indique qu’un démarrage, une commande de contrôle ou un processus surveillé s’est terminé en erreur.

Pour revoir les services actifs, arrêtés et leurs états, consultez aussi la liste des services avec systemctl.

Lire l’état du service avant toute relance

Remplacez nginx par votre unité. L’option --no-pager imprime le résultat directement dans le terminal, ce qui évite de rester dans less sur une session SSH.

sudo systemctl status nginx --no-pager

Regardez surtout la ligne Active:, le code de sortie et les dernières lignes affichées. Un port déjà occupé, un chemin absent, un certificat illisible ou une directive mal orthographiée apparaissent souvent ici. Si le service démarre un binaire qui possède son propre validateur, lancez d’abord ce validateur. Pour Nginx, par exemple :

sudo nginx -t

Ne lancez pas cette commande sur une machine qui n’utilise pas Nginx. Chaque service a sa syntaxe de vérification.

Remonter au message d’erreur avec journalctl

systemctl status ne montre qu’un extrait. Le journal de l’unité donne le contexte complet :

sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager

-b limite la recherche au démarrage courant. -n 50 garde les 50 dernières lignes si la panne est plus ancienne. Pour suivre une relance en direct, utilisez sudo journalctl -fu nginx dans une seconde session SSH. Le guide journalctl et les messages du dernier démarrage aide à élargir le diagnostic quand l’erreur touche plusieurs services.

Corriger, relancer, puis vérifier

Après une modification du fichier d’unité ou d’un drop-in systemd, rechargez la configuration. Cette étape ne redémarre pas le service.

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failed

is-active doit répondre active. Si le service écoute sur un port, contrôlez aussi le port et faites un test depuis le bon client. Une réponse active ne garantit pas qu’une application web, un proxy ou une base accepte déjà les requêtes.

Sur un service critique, gardez une seconde session SSH ouverte avant un redémarrage et copiez l’erreur exacte dans votre ticket ou vos notes. Vous éviterez de rejouer le même diagnostic au prochain incident.