fix(ci,#15091): copies de reference ai-01 — drop-in tracké, et le dépôt n'écrase plus la borne mémoire vivante

scripts/ci/docker/linux-runner/persist/ai-01/coursia-runner.service

@@ -34,6 +34,17 @@ StartLimitBurst=5
 
 [Service]
 Type=simple
+# LE 8 CI-DESSOUS N'EST PAS CE QUI TOURNE, et le lire comme tel est le piege
+# que ce commentaire existe pour fermer. La machine vivante porte un drop-in,
+# `coursia-runner.service.d/10-sizing.conf` (tracke a cote depuis #15091), qui
+# remet ExecStart a 4 slots et pose COURSIA_RUNNER_MEMORY=1536m.
+#
+# Sans ce drop-in, cette ligne demande 8 slots et supervise.sh l.82 retombe sur
+# son defaut `${COURSIA_RUNNER_MEMORY:-4g}` : 8 x 4096 = 32768 Mo contre un
+# budget de slice de 12288 Mo. Le garde de budget refuse, Restart=always
+# reboucle, le pool ne monte jamais -- la panne des quatre redemarrages manuels.
+# Ce fichier est marque « a deployer » dans persist/README.md : le deployer
+# SEUL reproduit la panne. Les deux fichiers partent ensemble, ou aucun.
 ExecStart=/usr/local/bin/coursia-runner-start.sh 8
 # ExecStop PASSE PAR LE WRAPPER (#15091). La version precedente appelait
 # supervise.sh directement, donc sans COURSIA_RUNNER_STATE_DIR : le sentinel

scripts/ci/docker/linux-runner/persist/ai-01/coursia-runner.service.d/10-sizing.conf

@@ -0,0 +1,76 @@
+# Copie de REFERENCE : l'original vit sous
+# /etc/systemd/system/coursia-runner.service.d/10-sizing.conf dans la distro
+# Ubuntu d'ai-01. Ce fichier n'est execute par personne ici (cf. persist/README.md).
+#
+# POURQUOI CE DROP-IN EST TRACKE (mandat user 2026-09-08)
+#
+# `coursia-runner.service` du meme repertoire declare `ExecStart=... 8` et
+# AUCUN `COURSIA_RUNNER_MEMORY`. supervise.sh l.82 retombe alors sur son defaut :
+#     MEMORY="${COURSIA_RUNNER_MEMORY:-4g}"
+# soit 8 x 4096 = 32768 Mo nominal demandes contre un budget de slice de
+# 12288 Mo. Le garde de budget REFUSE, `Restart=always` reboucle toutes les 30 s,
+# et le pool ne monte jamais. C'est la panne qui a impose QUATRE redemarrages
+# manuels de la machine dans la meme journee, par une intervention sur site.
+#
+# Ce drop-in etait UNTRACKED. `persist/README.md` marque la copie 8-slots
+# « a deployer » : la deployer telle quelle, sans ce fichier a cote, reproduit
+# la panne memoire a l'identique. C'est pour fermer cette porte que le drop-in
+# entre au depot -- le suivant qui deploiera ai-01 emportera les deux fichiers
+# ou aucun.
+#
+# IL NE SUFFIT PAS, ET LE DIRE SERAIT FAUX (mesure du 2026-09-08 a 14:49Z).
+# Ce fichier borne la MEMOIRE et laisse le CPU a son defaut. supervise.sh l.81
+# lit `CPUS="${COURSIA_RUNNER_CPUS:-3}"` : les 4 slots poses ci-dessous
+# demandent donc 4 x 3 = 12 vCPU. Avec les 4 waiters a 1 vCPU deja actifs, cela
+# fait 16 contre un budget de 8 (`COURSIA_RUNNER_CPU_BUDGET:-8`, l.101 du
+# wrapper). Mesure ce jour-la : unite `failed`, NRestarts=4, journal
+# « budget CPU inter-familles depasse : 16.00 vCPU demandes pour un plafond de 8 ».
+#
+# CE QUI A CHANGE ENTRE LE MATIN ET L'APRES-MIDI -- ce n'est PAS l'ordre de boot.
+# J'ai d'abord ecrit que si (`assert_cpu_budget()` compte les familles deja
+# actives, donc qui demarre en premier prend le budget). Le journal le refute :
+# les trois demarrages reussis du jour (08:33:52, 08:34:43, 09:29:41 CEST)
+# logguent `4 slot(s) ; cpus=3` alors que les waiters etaient DEJA a n=4
+# (08:33:52). 4 x 3 + 4 = 16 vCPU etaient donc DECLARES, et acceptes sans un mot.
+#
+# DECLARES, PAS CONSOMMES -- je l'avais d'abord ecrit trop fort. `coursia-ci.slice`
+# porte `CPUQuota=800%` (soit `cpu.max 800000 100000`) et etait armee tout du
+# long : le noyau en servait 8, avec throttling. Le garde manquant a retire le
+# REFUS LISIBLE, pas le plafond. La machine porte `nproc = 32` : 8 est le budget
+# consenti a la CI, pas la taille du processeur.
+#
+# L'ordre de boot est refute deux fois. Par arithmetique d'abord : 4 x 3 = 12
+# vCPU pour la seule famille `start`, contre un plafond de 8 -- elle echoue meme
+# en partant la premiere, waiters eteints. Aucun ordre ne la fait passer.
+#
+# Ce qui a change, c'est le GARDE : `assert_cpu_budget()` sort immediatement
+# quand le budget vaut 0 (l.422) et n'imprime alors RIEN. Sa ligne de succes
+# (l.444) est absente de TOUT le journal depuis le 2026-09-02. Le wrapper qui
+# porte `COURSIA_RUNNER_CPU_BUDGET:-8` a ete ecrit sur la machine a 09:47:21
+# CEST -- apres le dernier succes, avant la premiere ERREUR (16:11:53). Le garde
+# ne casse pas le parc : il rend visible une sur-souscription qui existait deja,
+# posee par ce drop-in et jamais confrontee au budget introduit par #15103.
+#
+# Le dimensionnement CPU reste OUVERT : trois configurations passent le garde
+# (4 slots x 1, 2 x 2, 1 x 3), et le choix demande une mesure -- un job reel a
+# ete vu a 129 % CPU, donc `cpus=1` l'etranglerait. Detail : persist/README.md
+# correction 5.
+#
+# Contenu ci-dessous : copie fidele du fichier vivant, mesure le 2026-09-08 via
+# `wsl.exe -d Ubuntu` (762 octets, unite `active`, NRestarts=0, ExecMainStatus=0).
+
+# Dimensionnement mesure (ai-01, 2026-09-08) -- mandat user "pas plus de RAM que
+# de disponible, avec de la marge".
+#
+# L'unite demandait 8 slots SANS cap memoire : supervise.sh retombait sur son
+# defaut 4g -> 32768 Mo nominal demandes contre un budget de 12288 Mo. Le garde
+# de budget refuse, Restart=always reboucle : le pool ne montait jamais.
+#
+# Cap par slot : 3072 -> 1536 Mo. Mesure docker stats sur des jobs reels :
+# 38 MiB et 160 MiB (ce dernier a 129 % CPU, genuinement occupe) contre un cap
+# de 3072 MiB, soit 1,2 % et 5,2 %. 1536 Mo reste ~10x le pic mesure.
+# Slots : 2 -> 4. Nominal total travail 6144 Mo, sous le budget 12288 Mo.
+[Service]
+Environment=COURSIA_RUNNER_MEMORY=1536m
+ExecStart=
+ExecStart=/usr/local/bin/coursia-runner-start.sh 4