CluPilotCloud/app/Services/Deployment
nexxo d1755f5921 Der Update-Agent sagt, dass er lebt — auch wenn er nicht arbeiten kann
Gemeldet: „seit 1.5.1 muss ich nach jedem Update install-agent.sh fahren,
sonst kommt kein Update mehr". Die Konsole meldete „Der Update-Dienst auf dem
Server laeuft nicht" und schickte genau dorthin.

Er lief. Das Journal zeigt zwei Tage lang lueckenlos 57-59 Laeufe je Stunde.
Aber ueber zweiundachtzig Minuten hinweg startete und endete jeder Lauf in
DERSELBEN Sekunde, waehrend ein arbeitender Lauf zwei braucht: sie stiegen
alle sofort wieder aus, an der Sperre eines anderen Vorgangs — `flock -n 9 ||
exit 0`. Lautlos. Kein Journal-Eintrag (systemd sieht einen sauberen Lauf),
keine Zeile in der Statusdatei, nichts in der Konsole.

Und die Statusdatei war die einzige Lebendmeldung, die es gab. Sie wird erst
nach rund 190 Zeilen geschrieben — nach dem `git fetch` und nach einem
`docker compose exec`, beide ohne Zeitgrenze und beide unter der Sperre. Ein
Lauf, der davor aussteigt, hinterlaesst nichts, und nach zwanzig Minuten
schliesst die Konsole daraus, der Dienst sei tot. Sie schloss falsch, und die
Handlungsanweisung dazu aendert an einer gehaltenen Sperre nichts.

Drei Aenderungen:

  * Ein Lebenszeichen (agent-alive.json) als ERSTES bei jedem Lauf, vor allem,
    was blockieren kann. Zwei Zustaende: `running` heisst "ich habe die Sperre
    und arbeite", `blocked` heisst "ich bin ausgestiegen" — mit `since` (seit
    wann ununterbrochen) und `held_by` (wer, per fuser und ps).
  * Zeitgrenzen: 45 Sekunden um den docker-exec, 120 um den git fetch. Ohne
    sie wartet ein Abruf gegen eine tote Verbindung, bis das Betriebssystem
    ihn nach vielen Minuten aufgibt — und haelt dabei die Sperre.
  * Die Konsole liest das Lebenszeichen statt der Statusdatei. Der Unterschied
    ist der Punkt: Status heisst "zuletzt ERFOLGREICH nachgesehen",
    Lebenszeichen heisst "zuletzt ueberhaupt gelaufen". Ein blockierter Agent
    gilt als lebendig, aber seine Zahlen zaehlen nicht mehr als aktuell —
    `behind` und `target_release` fallen auf "unbekannt", statt eine Stunde
    alte Auskunft als frisch auszugeben.

Statt "laeuft nicht" steht dort jetzt "laeuft, kommt aber seit HH:MM nicht an
die Arbeit", mit dem Prozess darunter.

Ein Agent von VOR dieser Aenderung schreibt die Datei nicht — fuer den gilt
weiter die alte Regel. Ihn dafuer fuer tot zu erklaeren waere derselbe Fehler
mit umgekehrtem Vorzeichen; ein Test haelt das fest.

Widerlegt und damit ausgeschlossen: Besitzrechte (Wirt, .env und Behaelter
fuehren alle 1001), das Ausführbar-Bit (100755 im Repo), systemds
Startdrosselung (seit v1.1.0 abgeschaltet), ein zwischengespeicherter Zustand
im Panel (es liest bei jedem Aufruf frisch) und eine Luecke im Timer (keine).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-04 01:31:19 +02:00
..
Release.php feat(deploy): releases you can pin to, and a version that tells the truth 2026-07-26 15:21:38 +02:00
UpdateChannel.php Der Update-Agent sagt, dass er lebt — auch wenn er nicht arbeiten kann 2026-08-04 01:31:19 +02:00
UpdateWindow.php Update on a schedule if the owner wants one, and say where incidents go 2026-07-29 15:01:54 +02:00