La machine refuse de s'arrêter : une demande n'est pas un interrupteur

Vous cliquez sur arrêter. La tâche démarre, la roue tourne, et trois minutes plus tard la machine fonctionne toujours. Vous finissez par cliquer sur stopper et elle meurt instantanément, ce qui soulève une question évidente : pourquoi la première action a-t-elle échoué alors que la seconde y arrive manifestement ?

Ce ne sont pas deux intensités de la même action. Ce sont deux choses entièrement différentes.

La distinction dont tout dépend

L'arrêt est une demande. La couche de virtualisation prie l'invité de s'éteindre lui-même, comme appuyer sur le bouton d'alimentation d'une machine physique prie un système d'exploitation de se fermer proprement. Ce qu'il advient de cette demande, c'est l'invité qui en décide.

Stopper est une coupure de courant. Cela retire immédiatement l'alimentation de la machine virtuelle, sans aucune conversation. La documentation en avertit en clair : stopper peut entraîner une perte de données, à utiliser avec prudence.

Une fois ces deux notions séparées, une machine qui refuse de s'arrêter cesse d'être mystérieuse. Elle ne refuse pas. Personne à l'intérieur n'a entendu la demande.

Qui est censé écouter

Il y a deux auditeurs possibles, et une machine en bonne santé en a au moins un.

Le gestionnaire du bouton d'alimentation du système d'exploitation. Sur un invité Linux il est normalement présent. Sur une image minimale, un appareil de type conteneur, ou un système entré dans une phase de démarrage précoce ou un shell de secours, il peut manquer.

L'agent invité. Lorsqu'il est activé et réellement en marche, il donne à la couche de virtualisation un canal direct vers l'intérieur, et la demande passe par là.

Si l'agent est éteint et que le gestionnaire du bouton est absent ou muet, la demande sort et n'arrive nulle part. On ne dit pas « non » à la couche de virtualisation. On ne lui dit rien, ce qui de l'extérieur ressemble exactement à la même chose et explique pourquoi la tâche semble se figer plutôt qu'échouer.

Si vos machines mettent régulièrement trop de temps à s'arrêter, vérifier que l'agent fonctionne vraiment est un meilleur premier réflexe que de raccourcir les délais.

Puis le délai, puis la force

L'attente est bornée. Par invité, le délai d'arrêt par défaut est de 180 secondes ; à son expiration, la machine est stoppée de force.

Un arrêt groupé de tout un nœud a son propre budget : il tente un arrêt propre, attend jusqu'à trois minutes par défaut, puis stoppe brutalement ce qui tourne encore.

La description honnête d'un arrêt sans surveillance est donc : demander poliment, attendre une durée fixe, puis débrancher. Si votre base de données a besoin de quatre minutes pour vider ses écritures, les valeurs par défaut ont déjà décidé qu'elle en aurait trois.

Augmentez le nombre, ne sautez pas la question

Il est tentant de traiter le délai comme le réglage à ajuster. Pour une machine qui a réellement besoin de plus de temps, l'augmenter est juste.

Mais une machine qui ne s'arrête jamais quelle que soit l'attente n'a pas un problème de délai, et lui donner dix minutes signifie seulement attendre dix minutes avant le même arrêt forcé. Cherchez d'abord si quelqu'un écoute.

Quand une tâche d'arrêt est déjà bloquée

Si une tâche d'arrêt reste plantée et que la machine doit descendre maintenant, il existe un moyen explicite de la stopper en passant outre la tâche d'arrêt en cours plutôt que de faire la queue derrière elle. Il existe précisément parce que le cas de la tâche bloquée est assez fréquent pour mériter une réponse.

Utilisez-le en sachant ce que c'est : toujours une coupure de courant, avec le même avertissement attaché.

Le cas qui prend les gens de court : la panne de courant

C'est ici que tout ce texte cesse d'être théorique.

Un script de panne de courant qui arrête les invités avant que les batteries ne lâchent hérite de toutes les propriétés ci-dessus. Il envoie des demandes. Les invités qui n'écoutent pas les ignorent. Le délai s'écoule. Puis tout ce qui tourne encore est stoppé brutalement, peut-être avec une batterie déjà faible et peut-être tout à la fois.

Deux choses méritent d'être vérifiées avant de se reposer sur un tel dispositif, et les deux sont bon marché :

Les invités répondent-ils réellement à une demande d'arrêt ? Testez-en un, chronomètre en main, un après-midi ordinaire.

Le budget total tient-il dans la batterie ? Les invités s'arrêtent l'un après l'autre, et les délais s'additionnent. Une rangée de machines qui prennent deux minutes chacune n'est pas un arrêt de deux minutes.

Un plan de panne de courant jamais répété est un plan qui sera répété une seule fois : dans le noir, sous la pression du temps.

Ce que fait Atlas

Atlas n'invente pas un troisième type d'arrêt. Demander et couper le courant sont les deux choses qui existent, et prétendre autrement serait un mensonge à conséquences.

Ce qu'il fait, c'est refuser de les confondre. Une action destructrice annonce qu'elle est destructrice avant que vous ne confirmiez, si bien que « stopper » n'arrive jamais déguisé en « arrêter » un peu plus ferme. Cette distinction est tout le sujet de cet article, et une interface qui présente les deux comme des boutons voisins de poids égal l'a déjà perdue.

Le résumé quotidien porte l'autre moitié : un redémarrage non planifié est signalé comme un fait. Une machine stoppée de force après un arrêt propre manqué ressemble, le lendemain matin, exactement à une machine qui a planté. Les deux méritent d'être remarquées.