Identifier les services systemd en échec sur un VPS Linux

Un service systemd en échec peut expliquer un site inaccessible, un serveur web arrêté, un serveur de jeu hors ligne ou une tâche de sauvegarde qui ne s’exécute plus. Sur un VPS Linux, quelques commandes permettent d’identifier le service concerné, de lire son journal et de vérifier si le problème revient après un redémarrage.

Voir les services systemd en échec

Connectez-vous en SSH avec un compte administrateur, puis demandez à systemd la liste des unités considérées comme échouées :

systemctl --failed

La sortie affiche notamment le nom de l’unité, son état et une description. Une ligne failed indique qu’une tentative de démarrage ou d’exécution s’est terminée en erreur. Notez le nom exact, par exemple nginx.service, apache2.service, docker.service, php8.3-fpm.service ou un service créé pour votre serveur de jeu.

Comprendre l’état du service

Remplacez mon-service.service par le nom trouvé dans la liste :

systemctl status mon-service.service --no-pager

Cette commande donne l’état actuel, le dernier code de sortie, les dernières lignes du journal et parfois la cause immédiate. Faites la différence entre un service arrêté volontairement et un service réellement en échec. Un service activé au démarrage peut aussi être correctement installé mais échouer lorsqu’il tente de charger une configuration, d’accéder à un fichier, d’utiliser un port ou de démarrer avec une adresse IP indisponible.

Lire les événements du journal

Pour obtenir les messages associés au service, utilisez le journal systemd :

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

L’option -u limite la recherche à l’unité demandée et -b cible le démarrage courant. Cherchez une erreur de syntaxe, un chemin inexistant, un port déjà utilisé, une permission refusée ou une dépendance indisponible. Pour afficher uniquement les messages récents, ajoutez par exemple --since "30 minutes ago".

Relier le service à l’application

Sur un VPS, systemd peut piloter des composants très différents : Nginx ou Apache pour un serveur web, PHP-FPM pour un site PHP, Docker pour des conteneurs, MySQL pour une base de données, un serveur Minecraft ou FiveM, ainsi que des agents de supervision et de sauvegarde. Le nom du service indique le composant à examiner, mais la cause peut se trouver dans un fichier de configuration ou une dépendance.

Vérifiez le contexte sans modifier inutilement la machine : espace disque et RAM disponibles, port écouté, résolution DNS, adresse IP, permissions et présence des fichiers attendus. Sur Ubuntu et Debian, consultez aussi la configuration du paquet concerné. Sur un serveur dédié ou un VPS utilisé pour plusieurs sites, un même port ou une limite de ressources peut expliquer plusieurs échecs.

Vérifier les dépendances et la protection du serveur

Un service peut dépendre d’un réseau disponible, d’un volume monté, d’une base de données ou d’un conteneur. Examinez ses dépendances et son unité avant de modifier le panneau de contrôle ou les fichiers de configuration :

systemctl list-dependencies mon-service.service
systemctl cat mon-service.service

Si l’application doit être accessible depuis Internet, vérifiez également la règle du firewall et le port d’écoute. Une sauvegarde récente ne répare pas un service, mais elle réduit le risque avant une modification importante. Sur une machine virtuelle, contrôlez aussi les ressources attribuées par l’hyperviseur : processeur, RAM et stockage.

VPS, serveur physique et outils d’administration

Le diagnostic reste comparable que vos services soient hébergés sur un VPS virtualisé ou sur un serveur physique dédié. La virtualisation ajoute toutefois une dépendance aux ressources attribuées à la machine virtuelle. Un administrateur peut gérer les services avec SSH et les commandes systemd, ou depuis un panel qui ne remplace pas la lecture des journaux. Cette méthode convient aussi aux scripts, aux applications web, aux bases de données et aux sauvegardes exécutés sur un serveur Linux.

Le choix de l’hébergeur ne change pas les commandes de diagnostic. En revanche, vérifiez les limites prévues par l’offre : système d’exploitation installé, espace de stockage, RAM, réseau et possibilité de redémarrer le serveur. Un serveur cloud, un VPS ou un serveur dédié peuvent tous héberger plusieurs services, mais chaque configuration demande un suivi régulier et des sauvegardes adaptées.

Corriger sans effacer les preuves

Avant de relancer un service, conservez les lignes d’erreur utiles. Vérifiez ensuite la configuration avec l’outil propre au logiciel, contrôlez les chemins et confirmez que les fichiers appartiennent au bon utilisateur. Après une correction, rechargez les unités si vous avez modifié un fichier de service :

sudo systemctl daemon-reload
sudo systemctl restart mon-service.service
sudo systemctl status mon-service.service --no-pager

Un redémarrage réussi ne suffit pas à conclure. Contrôlez les journaux après quelques instants et vérifiez que l’application répond réellement. Pour un serveur web, testez le site et le nom de domaine. Pour un serveur de jeu, testez aussi la connexion depuis le client ou le port prévu.

Vérifier après un redémarrage du VPS

Un service peut fonctionner après un redémarrage manuel mais échouer au démarrage automatique. Vérifiez son activation et la liste globale après reboot :

systemctl is-enabled mon-service.service
systemctl --failed

Si le service reste en échec, comparez les journaux du démarrage courant avec ceux du démarrage précédent. Ne masquez pas l’erreur avec une simple suppression de l’état : systemctl reset-failed nettoie l’indicateur, mais ne corrige pas la cause.

Quand demander une analyse plus approfondie

Escaladez le diagnostic si plusieurs services tombent en panne en même temps, si le disque est plein, si les permissions ont changé ou si le noyau signale un problème matériel. Conservez le nom de l’unité, l’heure de l’incident, la sortie de systemctl status et les extraits pertinents de journalctl. Ces éléments permettent de reproduire l’analyse sans partager de secrets, de mots de passe, de clés SSH ou de fichiers de configuration sensibles.

Pour poursuivre votre diagnostic, consultez aussi nos ressources sur l’analyse des journaux avec journalctl, la gestion de la taille des journaux systemd, la rotation des journaux Linux, le diagnostic d’une surcharge CPU et la surveillance de l’espace disque.