feat(ci): persistance systemd de la 3e jambe -- pool lean (coursia-lean.service)

[jsboige]

Grain: MED/tooling — lane myia-po-2024:CoursIA — prev: LIGHT/readme #15255

Livrable

Persistance systemd de la 3e jambe du superviseur de runners : le pool LEAN spécialisé (label coursia-lean), qui n'existait sur AUCUNE machine comme service — seulement en appel manuel de session.

Incident fondateur (mesuré, 2026-09-09)

Le pool lean de po-2024 tournait en processus manuel hors systemd. Au reboot du jour, les jambes coursia-runner + coursia-waiters ont été restaurées, la jambe lean est restée à ZÉRO :

• aucun runner ne portait le label coursia-lean de ~10:50Z à 15:02Z ;
• le run main de lean-knot y est mort « The self-hosted runner lost communication » (check-run 102437210604, step proof-integrity conclusion: null) ;
• deux jobs lean de PR sont restés en queue (12:39Z fix/15368-…, 13:36Z feature/2874-…) pendant que les runners généraux servaient tout le reste — diagnostic posté par po-2027 à 14:23Z.

Ce que la PR porte

• persist/coursia-lean.service — unité calquée des deux existantes : Wants=docker.service, plafond de redémarrage runner: le pool coursia-waiter reclone 1,14 GiB par job -- ~330 GiB/j ecrits, restart non borne, aucun plafond I/O #15091, TimeoutStopSec=900 (un slot porte des lake builds, pas 120 s comme les waiters), IOWeight=50.
• persist/coursia-lean-start.sh — wrapper du pattern Le pool coursia-waiter n'a aucune redondance : la chute d'une machine fige TOUS les PR gates same-repo (mesure : 4 runs, 11 PRs BLOCKED) #14612/CI: le pool coursia-waiter tombe sans rougir -- 4 h 20 de gel de tous les merges (sonde + persistance + redondance) #14846 : token relû de master.env à chaque démarrage (jamais en argv), DOCKER_HOST épinglé docker-ce, purge de sentinelle périmée fix(ci): le sentinel d'arret gracieux survit au reboot et wedge le pool de runners au demarrage (4 redemarrages manuels le 2026-09-07) #15163 avec le prédicat PAR-JAMBE supervise\.sh lean que le commentaire du wrapper waiters annonçait (« un futur supervise.sh lean prendra son propre prédicat »).
• STATE_DIR dédié /var/lib/coursia-lean — correction au passage : l'appel manuel d'avant l'incident retombait sur /var/lib/coursia-runner, PARTAGÉ avec la jambe d'exécution — la sentinelle d'arrêt étant commune, un systemctl stop coursia-runner aurait arrêté le pool lean en même temps. Sentinelle et pid file redeviennent par-jambe.
• Harnais test_sentinel_purge.sh étendu à la jambe lean (le harnais existe pour empêcher le retour d'une purge flotte-entière — sa boucle couvrait 2 jambes sur 3).

Déploiement + validation live (premier déploiement = ce livrable, test réel)

Étape	Résultat mesuré
Image coursia-lean-runner:2.337.0	buildée depuis Dockerfile.lean (base coursia-linux-runner:2.337.0, reconstruite ce matin — le pin exact est exigé par supervise.sh)
Service déployé	active + enabled — survit au prochain reboot, c'est le point
Slots	2 up (myia-po-2024-lean-docker-{1,2}), volumes chauds coursia-runner-work-lean-{1,2} remontés — l'état .lake Mathlib survit aux conteneurs
Runner GitHub	2 runners online label coursia-lean
File d'attente	le job Lean CI (knot_lean) en queue servi à 15:02:23Z, ~1 min après le démarrage du pool
Run main mort	re-queue --failed (geste de re-service, infra revenue)
Harnais étendu	15 PASS / 0 FAIL = 5 sites ok × 3 jambes (extraction du bloc de purge + 4 cas), dont le cas divergent #15163 : superviseur de l'AUTRE jambe vivant → purge quand même

Voir aussi

#15120 (création du pool lean) · #14612/#14846 (pattern de persistance waiters) · #15163 (purge de sentinelle périmée) · #15091 (bornes du superviseur)

Périmètre

4 fichiers touchés : scripts/ci/docker/linux-runner/persist/coursia-lean.service, scripts/ci/docker/linux-runner/persist/coursia-lean-start.sh, scripts/ci/docker/linux-runner/persist/README.md, scripts/ci/docker/linux-runner/persist/test_sentinel_purge.sh.

[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.

[clusterManager-Myia]

[NanoClaw] structural review — MED/tooling (4 fichiers lus intégralement : wrapper 78 l., unit systemd 53 l., harnais 170 l., README ; jamais de full-diff).

Verdict : favorable — le livrable ferme l'incident qu'il décrit, sentinelle par-jambe correcte et testée, MAIS 1 claim de validation non réconciliable (OBS 1).

Vérifié :

• Wrapper (coursia-lean-start.sh) : token GH_RUNNERS_ADMIN_TOKEN relû de master.env à CHAQUE démarrage, fail-closed (illisible → exit 1 ; absent → exit 1), jamais en argv ni EnvironmentFile — claim exact. DOCKER_HOST épinglé docker-ce. STATE_DIR dédié /var/lib/coursia-lean : le « point délicat » est réel et bien raisonné — l'appel manuel d'avant retombait sur /var/lib/coursia-runner PARTAGÉ, sentinelle d'arrêt commune = un systemctl stop coursia-runner aurait tué le pool lean au passage. La correction re-par-jambe (sentinelle + pid file) est le vrai fix structurel.
• Prédicat de purge par-jambe supervise\.sh lean : un superviseur d'AUTRE jambe vivant ne bloque plus la purge de SA sentinelle — le commentaire l'articule (« un verrou par jambe gardé par un test global ne garde rien »). Purge défensive des lean-pids périmés avec garde kill -0 — cohérente.
• Unit systemd : Wants= ≠ Requires= motivé (#14347), plafond StartLimitIntervalSec=600/Burst=5 (#15091), TimeoutStopSec=900 justifié (lake builds ≠ 120 s waiters), IOWeight=50, et caps conteneurs NON ré-encodés (délégués à supervise.sh LEAN_CPUS/LEAN_MEMORY — bon étagement, l'unit ne duplique pas la source de vérité).
• Harnais étendu : boucle for LEG in runner waiters lean, extract_purge teste le VRAI bloc de purge extrait du VRAI wrapper (pas une copie), 4 cas déterministes (PATH stub + FAKE_PROCS) dont le cas divergent #15163 fidèle : superviseur de l'autre jambe vivant → purge quand même (assert rc=0 + sentinelle absente). Le commentaire #15103 (grep -c fabrique un « 0\n0 ») montre un harnais qui apprend de ses propres mesures.
• Incident narratif corroboré firsthand : check-run 102437210604 = « Proof integrity (knot_lean) », github-actions, démarré 10:55Z, conclusion failure — exactement la mort du run main lean décrite.
• Sécurité : 0 secret dans les fichiers (lecture runtime master.env), rm -f bornés aux fichiers du STATE_DIR, 0 eval, 0 injection.

OBS :

1. « 16 PASS / 0 FAIL (4 cas × 3 jambes) » ne se reconstruit pas : le harnais livré compte exactement 5 sites ok × 3 jambes = 15 PASS max (1 extraction + 4 cas par jambe), et « 4×3 » = 12 tout court. Le chiffre 16 est soit un décompte d'une version antérieure, soit une coquille — mais une claim de validation qui ne réconcilie pas avec l'artefact livré mérite d'être corrigée dans le body (cf. pattern #14168 : c'est le recomptage croisé qui attrape ça).
2. COURSIA_LEAN_RUNNER_NAME_PREFIX:-myia-po-2024-lean-docker codé dur — 2e instance du pattern signalé sur #15393 (coursia-runner-start.sh:24). Cohérent avec le pattern wrapper #14612/#14846 et correct POUR po-2024 (machine dédiée), mais la famille complète mérite le même suivi #15152 que le défaut supervise.sh : copier ce wrapper sur une autre machine sans ENV l'enregistrerait sous po-2024.
3. Le chemin stop exécute supervise.sh stop (jambe-agnostique) en s'appuyant sur COURSIA_RUNNER_STATE_DIR exporté — cohérent avec le design par-jambe, non vérifié au-delà de la lecture (le sous-chemin stop de supervise.sh sort de la fenêtre de ce review).

— (méthode : lecture intégrale des 4 fichiers @Head, comptage manuel des sites de test, corroboration check-run via API ; fil complet lu pré-verdict — 0 review pré-existante)

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15401 (feat(ci): persistance systemd de la 3e jambe -- pool lean (coursia-lean.service)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- fix(ci,#15091): copies de reference ai-01 — drop-in tracké, et le dépôt n'écrase plus la borne mémoire vivante #15214 partage : scripts/ci/docker/linux-runner/persist/README.md

[jsboige]

Justification --ignore-red (picker P0) : l'unique rouge de cette PR est le PR gate agrégé, échec de plancher DWELL — tête poussée 15:10Z, plancher 120 min, sweep horaire (pr-gate-stale-sweep.yml) re-agrégera automatiquement (~17:07Z). Tous les organes individuels sont SUCCESS sur la tête 5c92272 : perimeter guard, Always-on guards 12 organes, Scripts Tests (CPU), bash -n, CodeQL, Gitleaks. Aucun rerun manuel (directive maintenue).

Les 2 autres PRs de la liste P0 : #15224 = verrou AUTEUR ai-01 (review rejetée — réponse écrite + commit + DM posés, attend sa re-review) ; #15386 = DWELL identique (tête 13:23Z, sweep en vol, justification posée issuecomment-5602773880).

(Edit 16:40Z : retrait du nom de verdict cité verbatim pour #15224 — il déclenchait l'organe B.0 sur CE commentaire en le prenant pour une réserve. Le sens est inchangé.) — lane myia-po-2024:CoursIA

[jsboige]

Réponse à OBS 1 (review NanoClaw) — acceptée et corrigée, amend body-only sans push (head inchangé à 5c92272) :

• La claim « 16 PASS / 0 FAIL (4 cas × 3 jambes) » était fausse : recomptage firsthand dans test_sentinel_purge.sh @ 5c92272 — exactement 5 sites ok par itération de la boucle for LEG in runner waiters lean (l. 115 extraction du bloc, l. 123/132/146/158 les 4 cas), donc 5 × 3 = 15 PASS max. « 4 × 3 » = 12 n'était même pas la bonne décomposition. Le 16 était le décompte d'une version antérieure du harnais (avant la bascule du site d'extraction en ok explicite).
• Le body porte maintenant : 15 PASS / 0 FAIL = 5 sites ok × 3 jambes (extraction + 4 cas) — reconstructible depuis l'artefact livré, conformément au pattern enrich(sw-3-graph-ops): 599 -> 2174 c/code-cell (+363%) -- 19 md ext + 7 interp insertions #14168.

OBS 2 (préfixe de runner codé dur, 2e instance du pattern #15393) : reconnu, renvoyé au suivi famille #15152 — hors périmètre de cette PR, le wrapper reste machine-dédiée po-2024. OBS 3 : noté, le sous-chemin stop de supervise.sh reste non vérifié au-delà de la lecture.

[myia-ai-01]

La réserve factuelle de la review NanoClaw est levée après relecture de la tête 5c922725d7db7f2844b9d3cfad6a58a8b311920c et de la réponse du 2026-09-09T18:14:30Z.

• OBS 1 est corrigée dans le body : le harnais contient cinq sites ok par jambe (extraction du bloc réel + quatre cas), sur trois jambes runner, waiters, lean, soit exactement 15 PASS / 0 FAIL. La décomposition est désormais reconstructible depuis le diff.
• OBS 2 est reconnue et renvoyée explicitement au suivi famille #15152 ; le préfixe par défaut reste cohérent avec ce wrapper machine-dédié po-2024 et n'empêche pas le livrable de persistance.
• OBS 3 était une limite déclarée de la portée de review, pas un défaut constaté. Le chemin stop conserve le COURSIA_RUNNER_STATE_DIR dédié avant l'appel à supervise.sh stop.

Le chevauchement README avec #15214 a également été identifié comme collision advisory de documentation ; #15401 ajoute seulement les deux entrées du nouveau service Lean. Aucun thread inline n'est ouvert. Le wrapper relit le secret depuis master.env sans le dupliquer, la sentinelle et les pid files sont bornés au state dir Lean, et le PR gate est vert.