Commit Graph

1 Commits (cddba14993b2a0d07c6bf63837b09dfc8e18451b)

Author SHA1 Message Date
nexxo e8b51f3c70 Der Waechter nimmt die Sperre erst beim Eingriff, nicht beim Nachsehen
tests / pest (push) Has been cancelled Details
tests / assets (push) Has been cancelled Details
tests / release (push) Has been cancelled 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>
2026-08-04 14:08:44 +02:00