Une boucle de plantage ressemble à une panne vue de loin : un service est inaccessible, redémarrer ne change rien, et l’échec se répète en cycle. La différence importe pour la façon d’y répondre. Une panne exige une enquête. Une boucle de plantage exige un disjoncteur.
Nous avons découvert cet angle mort en cherchant un tout autre problème — des ralentissements à l’échelle de la flotte, sans cause évidente. Les boucles de plantage étaient un suspect raisonnable; des rafales de redémarrage produisent exactement le genre de charge erratique qui ressemble à ce qu’on cherche. Ce n’était pas ça. Mais plusieurs projets morts depuis longtemps se sont révélés plantés en boucle malgré tout, plus de 160 démarrages échoués par semaine chacun, invisibles jusqu’à ce qu’on aille voir.
Le signal à surveiller
systemd (et la plupart des superviseurs de processus) limitent déjà une seule rafale de redémarrages, puis se réinitialisent. Ce n’est pas de la détection — c’est juste une limite de débit sans mémoire. Le vrai signal, c’est la répétition: surveiller le même événement « redémarré trop rapidement » se déclencher de nouveau après une accalmie. Une rafale, c’est une récupération normale. Trois rafales dans une fenêtre glissante, c’est un motif.
Cette distinction est tout le truc. Un délai plus long ou une limite de rafale plus généreuse ne règle rien — ça ne fait que retarder la même boucle sans fin.
Le cas vraiment difficile : impossible d’arrêter simplement d’appeler
Si vous hébergez les services d’autres personnes, certains seront des tâches de fond branchées sur un webhook, pas quelque chose qu’un humain visite. C’est le cas qu’une simple politique « veille si inactif » ne couvre pas.
Une application web morte attend, tout simplement; personne ne visite, rien ne se passe. Un robot mort continue d’être appelé — par une plateforme de clavardage, un webhook de paiement, quelle que soit l’intégration qui l’a déclenché à l’origine — selon un horaire externe que vous ne contrôlez pas et ne pouvez pas distinguer d’un appel légitime. Vous ne pouvez pas refuser l’appel pour éviter de réveiller un processus mort, parce qu’il ne l’est peut-être pas. Le réveil doit donc avoir lieu, il plante, et le prochain appel relance tout.
Mettre en veille pour économiser des ressources suppose que le réveil réussit. Quand ce n’est pas le cas, le même mécanisme qui économise des ressources sur un service en santé transforme un service mort en rafales récurrentes plutôt qu’en charge constante — pire pour une infrastructure partagée, pas mieux, parce que les rafales entrent en collision avec le trafic réel d’autres locataires au moment précis où elles se déclenchent.
Ce qu’on fait à ce sujet
On surveille le propre signal de limite de redémarrage de chaque unité. Trois occurrences dans une fenêtre glissante déclenchent un disjoncteur :
- L’unité est mise en pause — rien, pas même le prochain appel webhook, ne peut la redémarrer.
- On retourne une réponse claire et délibérée plutôt qu’une erreur brute.
- Le propriétaire est averti une seule fois, pas à chaque nouvelle occurrence.
La récupération passe par un déploiement, pas une remise à zéro manuelle. Un déploiement réussi est le signal du propriétaire lui-même qu’il croit le problème réglé; si ce n’est pas le cas, le disjoncteur se redéclenche de lui-même.