Boîte à Outils Informatique
Guide

Comment analyser un service systemd qui ne démarre pas

systemctl donne l’état immédiat du service tandis que journalctl explique souvent pourquoi le processus principal s’est arrêté.

ThématiqueLinux →
⌚ Environ 3 min de lecture
Voir mes favoris
Linux / Debian Intermédiaire 10 min

systemctl donne l’état immédiat du service tandis que journalctl explique souvent pourquoi le processus principal s’est arrêté.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Lire l’état

    Exécutez systemctl status sur le service.

  2. 2

    Consulter les logs dédiés

    Utilisez journalctl -u pour la période de l’incident.

  3. 3

    Vérifier la configuration

    Lancez la commande de test propre au service si elle existe.

  4. 4

    Contrôler dépendances et ports

    Vérifiez fichiers, permissions, DNS et ports occupés.

  5. 5

    Redémarrer après correction

    Relancez seulement après avoir identifié et corrigé l’erreur.

Commandes utiles

systemctl status nginx
journalctl -u nginx --since '-30 min'
ss -lntup

À retenir

  • Un restart répété peut effacer le contexte utile du premier échec.
  • Utilisez journalctl --since pour réduire le bruit.
  • Vérifiez les changements de configuration juste avant l’incident.
← Tous les guides
Complément technique

systemd : état, journal, dépendances et timers

Repères techniques

  • systemctl status donne le dernier état mais journalctl -u montre la chronologie et les messages complets du service.
  • Restart= peut provoquer une boucle qui masque la première erreur ; lire le journal depuis le boot ou l’horodatage initial.
  • Pour un timer, distinguer l’unité .timer de l’unité .service déclenchée et comparer LAST/NEXT.

Service / timer

Lire état, dépendances et journal sans redémarrer immédiatement.

systemctl status monservice
journalctl -u monservice --since today
systemctl list-timers --all

Pièges spécifiques

  • Un daemon-reload recharge les unités mais ne redémarre pas automatiquement le service.
  • Un timer réussi peut déclencher un service qui échoue : vérifier les deux unités.

Comment valider

  • Le service reste active/running sur plusieurs cycles ou le timer déclenche l’exécution attendue.
  • Le journal ne contient plus la cause initiale après le test représentatif.

Preuves et vérifications

systemctl status donne le dernier état mais journalctl -u montre la chronologie et les messages complets du service. Restart= peut provoquer une boucle qui masque la première erreur ; lire le journal depuis le boot ou l’horodatage initial.

Contrôle de résultat

Le service reste active/running sur plusieurs cycles ou le timer déclenche l’exécution attendue. Le journal ne contient plus la cause initiale après le test représentatif.

Point d’attention

Un daemon-reload recharge les unités mais ne redémarre pas automatiquement le service. Pour un timer, distinguer l’unité .timer de l’unité .service déclenchée et comparer LAST/NEXT.

Concepts liés

Référence primaire : systemd — service unit documentation.

♡ 0