Un `sudo journalctl` par ssh ÉCHOUE — pas de TTY pour le mot de passe — et
l'échec part sur stderr : stdout est vide, le grep en aval ne trouve rien, la
commande rend 0. Un relevé conduit ainsi ne dit rien et en a l'air.
C'est arrivé sur mes propres relevés des 28 et 29 : deux recherches « la ligne X
apparaît-elle ? » n'avaient RIEN LU. Et l'explication que j'avais donnée à
l'absence — « cette ligne est en qCDebug, le niveau n'est pas actif » — était
fausse : les lignes `D | NymeaEnergy:` sortent bel et bien sur .75. Une cause
plausible avancée pour un silence qu'on n'a pas mesuré, c'est le corollaire
LM-104 appliqué à l'instrument de mesure.
L'accès qui marche est écrit : `journalctl -u nymead`, SANS sudo, l'utilisateur
etm étant dans le groupe adm. Vérifié sur .75.
Et la règle qui va avec : une absence ne s'affirme que dans un flux dont on a
prouvé qu'il coule — citer une ligne qu'on a LUE dans la même fenêtre, puis dire
ce qui n'y est pas. RELEVE_LOTD.md est donné en modèle : il cite la ligne
« 0 créée(s), 0 mise(s) à jour, 2 INCHANGÉE(S) » qu'il a lue, PUIS conclut à
l'absence d'ECS-413 et de commutation. L'absence y porte parce que la présence
l'accompagne.
AUDIT DES RELEVÉS. Repris sur ce critère : aucun ne repose sur un journal vide.
RELEVE_LOTBbis §267 parle d'un dry-run reprepro, pas du journal. Le seul défaut
était dans la PROCÉDURE — TEST_TERRAIN.md prescrivait `sudo journalctl` dans son
helper logs(), celui qu'un opérateur lance pendant un essai, alors que sa ligne
51 était déjà juste. Le document se contredisait ; corrigé.
Consigné aussi : +etm27 posé sur .75 et ce qui y a été vérifié — avec les deux
vérifications qui n'y sont PAS observables et qu'il ne faut pas fabriquer. La
config du banc porte les rangs 1-2-3-4, réparée à la main hier soir ; la
migration se rencontrera sur une box cliente non migrée.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
bbe88c9bd6