Service Linux qui ne démarre plus : comment trouver et corriger l’erreur

Pourquoi un service Linux ne démarre-t-il plus ?

Un service Linux peut échouer au démarrage pour plusieurs raisons : une erreur de configuration, un fichier manquant, des permissions incorrectes, un port déjà utilisé ou une dépendance indisponible.

Sur un serveur web, ce problème peut rendre un site inaccessible. Sur un serveur de base de données, il peut empêcher une application de fonctionner.

La meilleure approche consiste à identifier la cause avant de tenter un redémarrage ou de modifier la configuration. Sur la plupart des distributions modernes, les commandes systemctl et journalctl permettent de commencer le diagnostic.

1. Vérifier l’état du service

Commencez par afficher l’état du service concerné. Par exemple, pour Nginx :

sudo systemctl status nginx

Remplacez nginx par le nom réel du service que vous souhaitez diagnostiquer.

La sortie contient généralement plusieurs informations utiles :

• Active : indique si le service fonctionne, est arrêté ou a échoué.
• Loaded : indique si son unité systemd a été chargée.
• Main PID : affiche le processus principal lorsqu’il est disponible.
• Recent logs : présente parfois les derniers messages associés au service.

Un état failed indique que le service a échoué, mais ne révèle pas nécessairement la cause exacte. Il faut examiner les journaux pour comprendre ce qui s’est passé.

Pour afficher les services actuellement en échec :

systemctl --failed

Cette commande est particulièrement utile lorsque plusieurs applications dépendent les unes des autres.

2. Lire les journaux avec journalctl

Les journaux fournissent souvent la réponse la plus précise.

Pour afficher les messages récents de Nginx :

sudo journalctl -u nginx -n 100 --no-pager

Voici ce que signifient les options :

• -u nginx filtre les messages liés à cette unité.
• -n 100 affiche les 100 dernières lignes.
• --no-pager affiche directement le résultat dans le terminal.

Pour suivre les nouveaux messages en temps réel :

sudo journalctl -u nginx -f

Cette commande est utile lorsque vous reproduisez le problème ou tentez un nouveau démarrage dans un autre terminal. Quittez le suivi avec Ctrl+C.

Vous pouvez également consulter les erreurs du démarrage actuel :

sudo journalctl -b -p err

Les messages doivent être interprétés dans leur contexte : une erreur ancienne ne correspond pas forcément à la panne actuelle.

3. Vérifier la configuration avant de redémarrer

Si le service utilise un fichier de configuration, vérifiez sa validité avant de tenter un redémarrage.

Pour Nginx :

sudo nginx -t

Si la configuration est correcte, Nginx indique normalement que la syntaxe est valide et que le test a réussi.

Pour SSH, selon la distribution et la version installée :

sudo sshd -t

Cette commande vérifie la configuration du serveur SSH. Si elle ne renvoie aucun message, cela signifie généralement que le test a réussi.

Ne modifiez pas plusieurs paramètres à la fois. Corrigez l’erreur identifiée, puis relancez le test correspondant. Cela permet de savoir quelle modification a réellement résolu le problème.

4. Vérifier si un port est déjà utilisé

Un service peut échouer parce qu’un autre processus utilise déjà le port dont il a besoin.

Pour afficher les sockets TCP et UDP en écoute :

sudo ss -lntup

Pour examiner spécifiquement le port 80 :

sudo ss -lntp 'sport = :80'

Si un autre programme occupe le port attendu, identifiez-le avant toute action.

Ne terminez pas automatiquement le processus concerné. Il peut s’agir d’un autre serveur web, d’un proxy ou d’une application légitime. Déterminez d’abord quel service doit utiliser ce port et corrigez la configuration si nécessaire.

5. Contrôler les permissions et les fichiers nécessaires

Un service peut également échouer lorsqu’il ne peut pas lire un fichier de configuration, accéder à un répertoire ou écrire dans un emplacement nécessaire.

Pour examiner les permissions d’un fichier :

ls -l /chemin/vers/le/fichier

Pour vérifier les permissions des différents répertoires du chemin :

namei -l /chemin/vers/le/fichier

Remplacez les chemins d’exemple par ceux mentionnés dans les journaux du service.

Évitez d’appliquer systématiquement des permissions très larges avec chmod -R 777. Cette méthode peut exposer des données et créer de nouveaux problèmes de sécurité. Il vaut mieux déterminer quel utilisateur exécute le service et lui accorder uniquement les droits nécessaires.

6. Vérifier les dépendances du service

Certains services dépendent d’autres composants : une base de données, un système de fichiers monté, une interface réseau ou un service d’authentification.

Pour examiner les dépendances déclarées :

systemctl list-dependencies nginx

Pour consulter les propriétés d’une unité :

systemctl show nginx --property=After,Wants,Requires

Ces informations aident à comprendre l’ordre de démarrage et les dépendances déclarées. Elles ne garantissent pas à elles seules que toutes les dépendances applicatives fonctionnent correctement.

Si une base de données est indisponible, par exemple, le service web peut démarrer techniquement tout en restant incapable de traiter les requêtes. Il faut donc vérifier les composants impliqués dans le problème.

7. Redémarrer le service après avoir corrigé la cause

Une fois le problème identifié et corrigé, vous pouvez tenter un redémarrage :

sudo systemctl restart nginx

Puis vérifiez immédiatement le résultat :

sudo systemctl status nginx

Si vous venez de modifier le fichier d’unité systemd lui-même, il peut être nécessaire de recharger sa configuration :

sudo systemctl daemon-reload

Cette commande ne remplace pas le test de configuration propre à l’application. Si vous avez modifié les fichiers Nginx, par exemple, exécutez également sudo nginx -t.

Sur un serveur de production, tenez compte des conséquences d’un redémarrage : les connexions actives peuvent être interrompues et une application peut subir une indisponibilité temporaire.

8. Exemple pratique : Nginx refuse de démarrer

Imaginons que Nginx échoue après une modification de configuration.

Commencez par :

sudo systemctl status nginx
sudo journalctl -u nginx -n 100 --no-pager

Si les messages indiquent une erreur de syntaxe, vérifiez le fichier de configuration :

sudo nginx -t

Corrigez la ligne signalée, puis exécutez à nouveau le test. Lorsque celui-ci réussit, redémarrez le service :

sudo systemctl restart nginx
sudo systemctl status nginx

Enfin, vérifiez que le serveur répond comme prévu depuis le réseau et que le site est accessible. Un service marqué comme actif n’implique pas toujours que toute l’application fonctionne correctement.

Les erreurs à éviter pendant le diagnostic

Lorsqu’un service ne démarre pas, certaines réactions peuvent compliquer la situation :

• Redémarrer plusieurs fois sans lire les journaux.
• Supprimer des fichiers de données pour tenter de corriger la panne.
• Modifier les permissions sans comprendre l’utilisateur qui exécute le service.
• Désactiver le pare-feu sans vérifier si le problème vient réellement du réseau.
• Modifier plusieurs fichiers simultanément sans conserver de copie de la configuration précédente.

Une approche méthodique est généralement plus rapide et plus sûre qu’une succession de tentatives aléatoires.

FAQ

Que signifie l’état failed dans systemctl ?

Il indique que l’unité a échoué selon son état enregistré par systemd. Consultez systemctl status et les journaux pour déterminer la cause.

Pourquoi journalctl n’affiche-t-il aucun message utile ?

Le service peut écrire dans un fichier journal distinct, utiliser un autre nom d’unité ou ne pas avoir produit de nouveaux messages. Vérifiez le nom exact du service et sa configuration de journalisation.

Dois-je utiliser restart ou reload ?

restart arrête puis redémarre le service. reload demande au service de recharger sa configuration sans effectuer nécessairement un arrêt complet. Tous les services ne prennent pas en charge le rechargement.

Comment consulter les erreurs après un redémarrage du serveur ?

Utilisez journalctl -b pour examiner les journaux du démarrage actuel. Selon la configuration du système, les journaux des démarrages précédents peuvent également être disponibles.

Conclusion

Lorsqu’un service Linux ne démarre plus, commencez par vérifier son état avec systemctl, puis examinez ses journaux avec journalctl. Testez ensuite sa configuration, ses ports, ses permissions et ses dépendances avant d’effectuer une nouvelle tentative de démarrage.

Cette méthode permet de résoudre de nombreuses pannes courantes sans supprimer de données ni modifier inutilement la configuration du serveur.