fix(ci,#15163): purger la sentinelle perimee au demarrage des jambes ai-01 -- predicat par-jambe + harnais

[myia-ai-01]

Grain: MED/guard — lane myia-ai-01:CoursIA — prev: MED/tooling #15103

Le fait

Un arret gracieux pose $STATE_DIR/stop. C'est un fichier : il survit au reboot. Au demarrage suivant, supervise.sh le trouve, refuse de demarrer, et l'unite systemd echoue. Le pool reste a zero jusqu'a intervention humaine.

Mesure ai-01, journal systemd du 2026-09-07 :

22:37:01  stop gracieux (sentinelle posee)
          <reboot>
22:53:29  Started coursia-runner.service
22:53:30  ERREUR: sentinel STOP_FILE present -- status=1/FAILURE

Restart=always n'aide pas : le refus est deterministe, chaque relance rejoue le meme echec. C'est arrive quatre fois dans la seule journee du 2026-09-07, chaque fois avec un deplacement physique jusqu'a la machine pour la redemarrer.

Le correctif

Un ExecStart est une demande explicite de demarrage. Si aucun superviseur n'est vivant, la sentinelle ne protege plus rien -- elle wedge. On la retire. Si un superviseur est vivant, un arret est en cours : on n'interfere pas, et on sort en erreur plutot que de lui couper l'herbe sous le pied.

Le predicat est PAR-JAMBE, pas flotte-entiere

C'est le seul point de conception qui compte ici. /var/lib/coursia-runner/stop et /var/lib/coursia-waiters/stop sont deux fichiers distincts. Un predicat supervise\.sh (start|waiters) repondrait « un superviseur QUELCONQUE vit-il ? » -- si bien que chaque jambe refuserait de purger sa propre sentinelle perimee tant que l'autre tourne.

Un verrou par jambe garde par un test global ne garde rien : il wedge. C'est exactement le defaut que ce correctif ferme, et le cas /4 du harnais est le seul qui distingue les deux predicats.

Pourquoi pas simplement --force dans l'ExecStart

--force purge inconditionnellement : le mettre dans l'unite rouvrirait le defaut que #14259 a ferme (annuler un arret gracieux reellement en cours). La purge livree ici est gardee par « aucun superviseur de cette jambe n'est vivant ».

Et sur la jambe waiters, la question ne se pose meme pas : --force n'existe que sur start (supervise.sh L602). Sur waiters et lean, une sentinelle perimee n'a aucune sortie automatique -- et c'est precisement la jambe ou le wedge a ete observe le 2026-09-07, resolu a la main.

Portee : cette PR est l'etape 1, et l'issue prescrit une etape 2

A dire clairement : #15163 prescrit de porter le correctif dans supervise.sh (une porte commune aux trois familles start/waiters/lean), pas dans les wrappers -- l'argument etant qu'il y a plusieurs wrappers et qu'ils auraient chacun besoin de la meme rustine. Cet argument est juste, et cette PR ne le contredit pas : elle le sequence.

Mesure de collision faite avant d'ecrire (L898), sur les trois PRs ouvertes qui touchent supervise.sh :

PR	lane	hunks sur supervise.sh
#15166	po-2026	cmd_start, cmd_waiters, cmd_lean
#15123	ai-01	cmd_start, cmd_waiters
#15182	ai-01	2 hunks anodins (L34, L89)

Les trois sites de la porte commune sont exactement les fonctions que #15166 et #15123 modifient. Y toucher maintenant force un rebase a une PR d'une autre lane. Les deux wrappers livres ici ne sont, eux, touches par aucune PR ouverte.

Ce que cette PR couvre donc : les deux jambes d'ai-01 -- la machine dont les quatre redemarrages ont ete payes en deplacements physiques. Ce qu'elle ne couvre pas, et qui reste du : le wrapper po-2024 (persist/coursia-runner-start.sh, sans purge, mesure faite) et la famille lean. La porte commune les prendra, en PR separee, une fois supervise.sh draine.

Correction a apporter a l'issue #15163

L'issue porte une section « Acceptance » integralement cochee [x], decrivant any_supervisor_alive(), stop_sentinel_gate() et des « Tests 20-22 » dans test_supervise_guards.sh. Rien de tout cela n'existe :

$ git grep -n 'stop_sentinel_gate\|any_supervisor_alive' origin/main -- scripts/ci/docker/linux-runner/
(vide)
$ grep -n 'stop_sentinel_gate\|any_supervisor_alive' scripts/ci/docker/linux-runner/supervise.sh
(vide)            # controle positif du grep : 'cmd_start' -> 2 occurrences

J'ai ecrit cette issue moi-meme (myia-ai-01, 2026-09-08T03:01:04Z) et coche une acceptance sur du travail non livre. Le body est corrige dans le meme geste que cette PR : les cases repassent a [ ] et l'etat reel y est ecrit.

Le harnais -- et la seule raison de le croire

persist/test_sentinel_purge.sh, 4 cas par jambe. Il extrait le bloc du fichier de production (sed -n '/^# --- PURGE SENTINELLE PERIMEE/,/^# ---...$/p') au lieu de le reimplementer, et assert que l'extraction contient bien le rm -f -- sans quoi un sed qui rate rendrait vert en ne testant rien.

11 PASS / 0 FAIL
==> rc=0  (mesure AVANT tout pipe)

rc est capture dans OUT=$(...) avant tout | sed : un rc=$? apres un pipe lit le code du dernier maillon, et cette suite a deja imprime rc=0 sur un 6 PASS / 4 FAIL.

Le premier run etait rouge, et le rouge etait correct. 6 PASS / 4 FAIL : les cas 2 et 4 echouaient sur les deux jambes, parce que le harnais tourne sur la machine de production, ou les vrais superviseurs sont active -- le pgrep du systeme les trouvait, donc le cas « aucun superviseur vivant » etait intestable. D'ou le stub pgrep en tete de PATH, qui lit $FAKE_PROCS et applique le motif -f recu comme ERE. Le stub est lui-meme valide par un controle positif et negatif avant que ses resultats soient crus (PASS: stub pgrep discrimine start vs waiters).

Controle positif du harnais -- un vert ne prouve rien tant que l'outil n'a pas montre qu'il sait rougir. Les deux regressions que cet organe existe pour attraper, injectees dans des copies :

Regression injectee	Verdict
predicat flotte-entiere supervise\.sh (start|waiters) (le defaut #15163)	9 PASS / 2 FAIL, rc=1 -- les deux cas /4 rougissent
bloc de purge purement retire	1 PASS / 2 FAIL, rc=1 -- « bloc de purge INTROUVABLE »

Le cas /4 est donc le seul qui separe le correctif de ce qu'il corrige, et il le fait mesurablement.

Verification

• bash -n sur les deux wrappers (porte par le harnais via l'extraction + execution reelle du bloc).
• Fins de ligne : CR=0 sur les trois fichiers, instrument valide par controle positif (un crlf_probe.txt fabrique rend CR=2) -- grep -c $'\r' degenere en grep -c '' sous Git Bash et rendait le nombre de lignes. .gitattributes couvre deja *.sh text eol=lf (L39).
• Les deux wrappers sont deployes et actifs sur ai-01 depuis le 2026-09-07 ; les deux unites sont active, sentinelle absente. Cette PR met en git ce qui tourne.

Suite nommee (G-VAR-1)

Cette PR est de genre guard -- classe META : elle ne tient pas le plancher du cycle. Le grain de contenu qui le portera est la QA visuelle des decks slides escaladee a ma lane par po-2026 (capability vision) : #15131 (07-elargissements, 6 slides, ?clicks=99), puis ses sœurs #15049 et #15051.

See #15163

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[jsboige]

[Hermes] — fix(ci,#15163) : APPROVE.

Vérifié firsthand sur po-2026 (fichiers fetchés à la tête 4b92f60) :

• Harnais exécuté : test_sentinel_purge.sh → 11 PASS / 0 FAIL, rc=0 — les 4 cas par jambe, y compris le cas 4 divergent (sentinelle de CETTE jambe + superviseur de l'AUTRE vivant → purge quand même), qui seul distingue le correctif du prédicat flotte-entière.
• Wiring vérifié : chaque wrapper exporte son propre COURSIA_RUNNER_STATE_DIR (runner l.70 /var/lib/coursia-runner, waiters l.39 /var/lib/coursia-waiters) avant le bloc de purge — chaque jambe teste bien SA sentinelle.
• Qualité du harnais : le bloc testé est extrait du dépôt via sed (pas une réécriture qui divergerait), stub pgrep avec contrôle d'instrument (sait dire oui ET non), compteurs en fichiers (piège sous-shell #15103 documenté). Le choix du stub est motivé par une mesure réelle (6/4 FAIL faux sur ai-01 avec le vrai pgrep — machine porte de vrais superviseurs).
• Issue-First match : méthode PR = méthode documentée dans #15163 (« Livré (PR #15188) »). Reste-du (porte commune dans supervise.sh) explicitement reporté dans l'issue pour éviter les collisions avec #15166/#15123/#15182 — décision saine, l'issue reste OPEN jusqu'ici.
• Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).

Fix complet pour le scope livré, root cause fermée, régression détectable par le cas 4. RAS.