e8b51f3c70
tests / pest (push) Waiting to run
Details
tests / assets (push) Waiting to run
Details
tests / release (push) Blocked by required conditions
Details
Der Update-Agent meldete dauerhaft "kommt nicht an die Arbeit", obwohl nichts kaputt war. Wächter und Agent haben beide einen minütlichen Zeitgeber und nahmen beide `.agent.lock` in ihren ersten Zeilen — bevor sie wussten, ob sie überhaupt etwas tun würden. Der Wächter tut an fast jedem Tag nichts: seine vier Prüfungen sind allesamt lesend. Er hielt die Sperre trotzdem, jede Minute; der Agent kam leer aus und schrieb einen Übersprung-Vermerk. Weil der Agent der ist, der an die Konsole berichtet, stand dort eine Dauerstörung, während beide Dienste genau das taten, was sie sollten. Der Wächter sieht jetzt ungesperrt nach und nimmt die Sperre erst, wenn wirklich etwas zu richten ist — im gesunden Fall fasst er sie nie an. Wo er eingreift, wird die Lage nach dem Nehmen der Sperre noch einmal geprüft: zwischen dem ungesperrten Blick und der Sperre kann ein Update fertig geworden sein, und `--force-recreate` auf gesunde Container reißt jede offene Verbindung ab. Versetzte Zeitgeber wären nur seltener gewesen, nicht weg — zwei Takte derselben Länge wandern gegeneinander, und systemd zieht sie über AccuracySec aktiv auf gemeinsame Weckpunkte zusammen. Eine zweite Sperre wäre schlimmer als der Fehler gewesen: dann liefe der Wächter mitten in ein Update hinein. Dazu zwei Dinge, die derselbe Vorfall aufgedeckt hat: - Vierzehn Aufrufe nach draußen standen im Wächter ohne Frist, alle unter der Sperre. Der Agent hat `timeout -k` am 4. August gelernt, der Wächter nie — ein `docker compose exec`, das auf den Daemon wartet, hätte die Sperre unbegrenzt gehalten. - Ein übersprungener Lauf sah im Journal aus wie ein erfolgreicher: der Agent beendet sich sauber, systemd meldet Starting → Deactivated. Das hat die Fehlersuche zweimal in die falsche Richtung geschickt. Er sagt es jetzt, mit Halter und Zähler in der Zeile. WatchdogLockContentionTest lässt beide echten Skripte gegeneinander laufen statt die Sperrenlogik nachzurechnen — und prüft beide Richtungen: der Agent kommt an die Arbeit, während der Wächter nur nachsieht, und der Wächter hält still, während ein Update die Sperre hält. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| bootstrap | ||
| caddy | ||
| lib | ||
| clupilot.env.example | ||
| install-agent.sh | ||
| install.sh | ||
| rescue-tunnel.sh | ||
| update-agent.sh | ||
| update.sh | ||
| watchdog.sh | ||