Problème
Le serveur a redémarré, après une coupure de courant, une mise à jour de noyau ou une intervention de l'hébergeur, et un service n'est pas revenu. Rien n'a prévenu : la machine répond, les autres services fonctionnent, et la panne n'est découverte que lorsqu'un utilisateur appelle, parfois plusieurs jours plus tard. Le service marchait pourtant depuis des mois sans le moindre incident, ce qui rend la cause difficile à admettre : il n'avait jamais été activé au démarrage, il avait seulement été lancé à la main le jour de son installation, et il a survécu exactement aussi longtemps que la machine n'a pas redémarré.
Solution recommandée
Séparer deux notions que le gestionnaire de services distingue mal à l'oeil : un service démarré tourne maintenant, un service activé sera relancé au prochain démarrage de la machine. Les deux sont indépendants, et c'est tout le sujet : on peut tourner sans être activé, ce qui donne la panne décrite ici, comme on peut être activé sans tourner, parce que le démarrage a échoué. Le traitement se fait donc en deux gestes, dans cet ordre : relancer le service pour rétablir le service rendu, puis l'activer pour qu'il revienne seul. Ensuite vient la partie qui a le plus de valeur : passer en revue tous les autres services de la machine pour trouver ceux qui tournent sans être activés, avant le prochain redémarrage. La même panne y dort déjà, et personne ne le sait.
Matériel & outils
Un accès administrateur au serveur, en console ou par SSH, le gestionnaire de services du système, systemctl sous les distributions Linux modernes, journalctl pour lire les journaux d'une unité, la console d'administration de l'hébergeur ou une console physique pour le cas où la machine ne remonterait pas, la console services.msc ou les commandes Get-Service et Set-Service sous Windows Server, docker ou docker compose si le service est un conteneur, et une supervision, même minimale, pour être prévenu la prochaine fois
Étapes
1. Constatez d'abord l'état réel du service, avec systemctl status suivi de son nom. La sortie donne en une fois les deux informations qui comptent, et elles sont sur deux lignes différentes : la ligne Loaded se termine par enabled ou disabled, qui dit si le service est prévu au démarrage, et la ligne Active dit active (running) ou inactive (dead), qui dit s'il tourne en ce moment. C'est ce couple, et lui seul, qui oriente tout le reste 2. Si la lecture de cette sortie vous laisse un doute, posez les deux questions séparément : systemctl is-active suivi du nom répond active ou inactive, systemctl is-enabled suivi du nom répond enabled ou disabled. Retenez la différence une fois pour toutes : is-active parle du présent, is-enabled parle du prochain démarrage. Confondre les deux, c'est croire un service réparé alors qu'il redisparaîtra à la coupure suivante 3. Le cas de cette fiche est la combinaison inactive et disabled : le service ne tourne pas, et rien ne prévoyait de le lancer. Il n'y a pas de panne à diagnostiquer, il y a une activation qui n'a jamais été faite. Relancez-le immédiatement avec systemctl start suivi du nom, vérifiez avec systemctl status qu'il est passé à active (running), et confirmez côté usage que le service rendu est bien revenu 4. Rendez maintenant le retour durable, ce qui est un geste distinct du précédent : systemctl enable suivi du nom inscrit le service au démarrage de la machine. Il ne le démarre pas pour autant. La forme systemctl enable --now fait les deux d'un coup, démarrer et activer, et c'est celle à prendre l'habitude d'utiliser à l'installation d'un service. Relisez ensuite systemctl is-enabled : la réponse doit être enabled 5. Autre réponse possible à is-enabled, et autre traitement. La réponse masked signale un service volontairement neutralisé, souvent par un prédécesseur et pour une bonne raison : cherchez laquelle avant de le libérer avec systemctl unmask. La réponse static signale une unité qui ne s'active pas directement et qui est tirée par une autre : activez alors le service parent, pas celui-là. La réponse indirect renvoie au même raisonnement 6. Cas différent et fréquent, le service était bien activé mais il a échoué au démarrage. Le signe : is-enabled répond enabled alors que le service ne tourne pas, et systemctl status affiche failed. Ici l'activation n'est pas en cause, la machine a bien essayé de le lancer. Listez tout ce qui a échoué au dernier démarrage avec systemctl --failed : cette seule commande, passée après chaque redémarrage, vaut un audit à elle seule 7. Lisez alors les journaux du service pour le démarrage en cours, avec journalctl -u suivi du nom de l'unité et de l'option -b, qui limite la sortie au démarrage courant. Ajoutez -e pour aller directement à la fin. La cause tient presque toujours dans les dernières lignes : un fichier de configuration modifié et jamais rechargé depuis, un port déjà occupé, un droit manquant, un certificat absent 8. Troisième cas, le service part trop tôt, et c'est une panne d'ordre de démarrage, pas d'activation. Le signe est caractéristique : le service échoue au démarrage de la machine, mais un simple systemctl start lancé à la main quelques minutes plus tard réussit sans rien changer d'autre. Quand relancer suffit, c'est que la dépendance manquait au moment du démarrage, pas que la configuration est fausse 9. Les deux causes dominantes de ce troisième cas sont un service qui dépend d'un autre pas encore prêt, typiquement une application lancée avant sa base de données, et un stockage pas encore monté, typiquement un partage réseau ou un disque distant sur lequel l'application doit écrire. Le réseau est le piège le plus commun : la machine considère le réseau comme disponible bien avant qu'une adresse soit réellement attribuée 10. La réparation ne consiste jamais à modifier le fichier d'unité livré par le paquet, qui serait écrasé à la prochaine mise à jour, mais à écrire un complément avec systemctl edit suivi du nom du service, qui crée un fichier de surcharge propre à votre machine. On y déclare que l'unité doit attendre une autre unité, ou attendre que le réseau soit réellement établi, ou attendre le montage d'un point précis. Après toute modification d'unité, systemctl daemon-reload est obligatoire, sans quoi le gestionnaire continue de lire l'ancienne version 11. Pour un stockage distant, la vraie réparation est souvent plus simple et se fait côté montage : déclarer le point de montage comme dépendant du réseau dans la table des systèmes de fichiers, ce qui retarde son montage et, par ricochet, celui des services qui en dépendent. Une entrée de montage réseau déclarée sans cette précaution est aussi la première cause de serveur qui refuse de terminer son démarrage, un incident bien plus grave que le service manquant 12. Un mot sur le redémarrage automatique en cas de plantage, souvent confondu avec l'activation alors qu'il répond à une autre question. L'activation traite le démarrage de la machine, la politique de redémarrage traite le programme qui meurt en cours de route. Elle se déclare dans l'unité, par une directive de redémarrage assortie d'un délai entre deux tentatives. Comme pour les conteneurs, elle ne répare rien : elle relance en boucle un service qui échoue et transforme une panne visible en panne silencieuse, donc posez-la en plus d'une supervision, jamais à sa place 13. Voici maintenant la partie qui rapporte le plus, et qu'il faut faire même si le service fautif est déjà réparé : l'audit préventif. Listez les services actuellement en fonctionnement avec systemctl list-units --type=service --state=running, puis listez ceux qui sont prévus au démarrage avec systemctl list-unit-files --type=service --state=enabled. Tout ce qui figure dans la première liste et pas dans la seconde est une panne programmée pour le prochain redémarrage. Pour un doute sur un service précis, systemctl is-enabled accepte plusieurs noms à la suite 14. Passez cette liste en revue au lieu de tout activer en bloc. Certaines entrées sont normales : une unité tirée par une autre, un service lancé à la demande par une socket, une tâche ponctuelle. Pour chaque élément qui doit réellement survivre à un redémarrage, activez-le avec systemctl enable, et notez-le : cette liste est aussi l'inventaire des services que la machine rend, document qui manque presque toujours 15. Regardez les conteneurs à part, car leur mécanique est la même mais les réglages sont ailleurs. Un conteneur revient après un redémarrage si sa politique de redémarrage le prévoit, unless-stopped étant le réglage courant, et à la condition que le moteur Docker lui-même soit activé au démarrage, ce qui se vérifie exactement comme pour tout autre service. Vérifiez les deux : un conteneur bien réglé sur un moteur non activé ne reviendra pas davantage. Pour une pile décrite dans un fichier compose, la politique se déclare service par service. Le même raisonnement vaut pour les tâches planifiées : une minuterie doit être activée, pas seulement lancée, et la fiche sur le certificat expiré détaille ce cas précis, où une minuterie de renouvellement disparue provoque une panne des mois plus tard 16. Terminez par le seul contrôle qui prouve quelque chose : redémarrer volontairement la machine, et regarder ce qui remonte. Tant que ce test n'a pas été fait, vous savez ce qui est activé, pas ce qui fonctionne. Sur un serveur de production, cela se prépare : choisir une fenêtre annoncée et hors production, vérifier que la sauvegarde est récente et restaurable, s'assurer d'un accès console indépendant du système, par l'interface de l'hébergeur ou une carte d'administration physique, pour le cas où la machine ne remonterait pas en réseau. Vérifiez avant de redémarrer que la table des systèmes de fichiers ne contient pas d'entrée obsolète, première cause de machine bloquée au démarrage, et prévenez les personnes concernées 17. Après le redémarrage, contrôlez dans cet ordre : systemctl --failed doit être vide, systemctl is-system-running doit répondre running et non degraded, puis testez chaque service par son usage réel et non par son état affiché. Un service marqué actif qui ne répond pas sur son port n'est pas revenu. Prenez l'habitude de faire ce test après toute installation de service, tant que la machine est encore jeune et qu'un redémarrage ne coûte rien 18. Posez enfin une supervision, car c'est la seule chose qui aurait évité les jours de panne silencieuse. Une sonde par service exposé, qui vérifie la réponse réelle et alerte en cas de silence, transforme cette panne en notification de quelques minutes. Sans elle, la prochaine coupure de courant produira exactement le même scénario, avec un autre service
Coût estimé
0 €, hors temps passé : toutes les commandes citées sont livrées avec le système. Un coût n'apparaît que pour la supervision, si vous choisissez un service hébergé plutôt qu'un outil installé sur vos machines
Limites
Ne couvre pas les distributions Linux qui n'utilisent pas systemd, dont les commandes et les noms d'états diffèrent, même si la distinction entre démarré et activé y existe aussi. Les noms d'unités, les chemins de configuration et les fichiers de surcharge varient d'une distribution à l'autre : vérifiez-les sur la machine plutôt que de recopier un exemple. Sous Windows Server, le raisonnement est identique mais le vocabulaire change : c'est le type de démarrage d'un service, Automatique ou Manuel, qui joue le rôle de l'activation, et un service en Manuel lancé à la main produit exactement la même panne. Ne traite pas un serveur qui ne redémarre pas du tout, ni une machine virtuelle qui ne se rallume pas après une coupure de son hôte, qui sont des incidents d'un autre ordre. Ne traite pas non plus le service qui tourne mais répond mal.
Erreurs fréquentes
Lancer systemctl start, voir le service revenir, et refermer le sujet : la panne reviendra à l'identique au prochain redémarrage, parce que rien n'a été activé. Croire que systemctl enable démarre le service, et laisser un serveur sans service jusqu'au redémarrage suivant. Lire la ligne Active de la sortie de statut en pensant y trouver l'information sur le démarrage automatique, alors qu'elle parle du présent et que c'est la ligne Loaded qui répond. Ne traiter que le service qui a lâché, alors que l'audit prend cinq minutes et trouve presque toujours d'autres services dans le même état. Modifier directement le fichier d'unité fourni par le paquet plutôt que d'écrire une surcharge, et perdre la modification à la mise à jour suivante. Oublier systemctl daemon-reload après avoir modifié une unité, puis conclure que le changement n'a servi à rien. Ajouter un redémarrage automatique en cas d'échec pour masquer un service qui ne démarre pas, ce qui donne une machine qui semble en bonne santé et un service qui n'a jamais rendu de service. Redémarrer un serveur de production pour tester, sans fenêtre annoncée, sans sauvegarde vérifiée et sans accès console de secours.
Alternatives
Plutôt que d'auditer une machine après coup, prendre pour règle d'installation de toujours activer et démarrer en une seule commande, avec la forme qui fait les deux : la panne décrite ici disparaît à la source. Sur un parc de plusieurs serveurs, faire décrire l'état attendu par un outil de gestion de configuration, qui déclare qu'un service doit être présent, démarré et activé, et qui corrige les écarts à chaque passage : c'est la seule réponse qui tienne au-delà de quelques machines. Pour un service maison, le faire fonctionner en conteneur avec une politique de redémarrage, ce qui déplace la question vers un réglage unique et visible dans le fichier de description. Et dans tous les cas, garder une supervision externe : elle ne remplace pas l'activation, mais elle est ce qui fait la différence entre une panne de dix minutes et une panne de trois jours.
Besoin d'un accompagnement personnalisé ?
Cours 1:1, conseil de solution, ou simplement une question précise - contacte-moi directement.