Fix systemd oneshot upgrade handoff deadlock
This commit is contained in:
1 parent
56fbcdad74
commit
898df2e926
5 files changed
+190
-20
No files matched your search
+15
-2
@@ -261,6 +261,17 @@ Dateisperre. Der Starter übergibt den langen Ablauf an eine systemd-Unit; das
|
||||
Ergebnis bleibt im Migrationsordner erhalten. Ein kombinierter Rollback stellt
|
||||
Paketdateien und die vorherige Hauptkonfiguration wieder her.
|
||||
|
||||
Die Übergabe nutzt `systemd-run --no-block` mit `Type=oneshot`: Der Starter wartet
|
||||
nur auf die Annahme des Auftrags, gibt danach zuerst die Backup-Sperre und dann
|
||||
die Update-Sperre frei. Der Worker erwirbt beide selbst und darf nur mit einem
|
||||
weiterhin als `QUEUED` freigegebenen Migrationsstand beginnen. Bei einer
|
||||
fehlgeschlagenen Übergabe wird diese Freigabe unter gehaltener Sperre entzogen.
|
||||
Der Worker richtet Fehlerprotokoll und EXIT-Trap vor dem maximal 60-sekündigen
|
||||
Warten auf die Update-Sperre ein. Erst `SUCCESS` belegt das Gesamtresultat.
|
||||
Das behebt das gegenseitige Warten in den früheren Paketen: Ohne `--no-block`
|
||||
wartete der Starter auf den oneshot-Abschluss, während der Worker auf seine
|
||||
Sperre wartete. Ursache, Diagnose und Wiederanlauf beschreibt die Update-Anleitung.
|
||||
|
||||
Der Abnahmelauf nutzt `app-backup.sh --no-retention`: keinerlei lokale oder entfernte
|
||||
Löschung alter Sicherungssätze. Nach Upload/Rücklesevergleich prüft zusätzlich
|
||||
`app-restore.sh --remote-run ... --verify-only` den erneut heruntergeladenen Satz.
|
||||
@@ -304,7 +315,7 @@ Die Entfernung der drei DB-Dateien aus dem aktuellen Baum löscht deren Historie
|
||||
|
||||
Reproduzierbar mit `tests/Dockerfile` und `tests/run.sh`. Der Container bekommt das Repository nur lesbar und benötigt während der Tests kein Netzwerk. Die MariaDB läuft ohne TCP-Port in einem temporären Verzeichnis. systemd/occ werden simuliert; alle eigentlichen Archive, Dateikopien, Dumps/Imports und Crypt-Operationen sind real.
|
||||
|
||||
Ergebnis des lokalen Abschlusslaufs am 10.09.2026: **34 Tests erfolgreich**, Shell-Syntax und ShellCheck ohne Befund. Testumgebung: Debian 13.6, MariaDB 11.8.6, rclone 1.60.1-DEV (Distributionspaket), ShellCheck 0.10.0. Diese Versionsangaben beschreiben die Testumgebung, keine Empfehlung für die Produktivversion.
|
||||
Ergebnis des lokalen Abschlusslaufs am 10.09.2026: **37 Tests erfolgreich**, Shell-Syntax und ShellCheck ohne Befund. Testumgebung: Debian 13.6, MariaDB 11.8.6, rclone 1.60.1-DEV (Distributionspaket), ShellCheck 0.10.0. Diese Versionsangaben beschreiben die Testumgebung, keine Empfehlung für die Produktivversion.
|
||||
|
||||
Geprüfte Fälle umfassen:
|
||||
|
||||
@@ -321,6 +332,8 @@ Geprüfte Fälle umfassen:
|
||||
- Paketupdate mit Erhalt von Config/Zeitplan und ausführbarem Rollback.
|
||||
- Selbstentpackendes Transferpaket mit erfolgreichem Komplettlauf und kombiniertem Konfigurations-/Paket-Rollback.
|
||||
- Abbruch vor Änderungen bei Vorprüfungsfehlern, gestoppter Timer bei fehlgeschlagenem Abnahmebackup, Ablehnung beschädigter Pakete.
|
||||
- Übergabe an einen vom Starter unabhängigen Prozess (systemd-run im Test simuliert), ausdrückliche Cron-Policy und Writer-Wartezeit/Timeout.
|
||||
- Übergabe an einen vom Starter unabhängigen Prozess: Das systemd-run-Testmodell wartet bei `Type=oneshot` ohne `--no-block` auf das Worker-Ende. Der Regressionstest scheiterte am bisherigen gegenseitigen Sperrwarten und besteht nach dem Fix.
|
||||
- Abgewiesene systemd-Übergabe, zurückgezogene Freigabe bei bereits eingereihtem Auftrag und persistente Fehlerprotokolle bei Sperr-Timeout; jeweils ohne Installationsänderung oder Timer-Stopp.
|
||||
- Ausdrückliche Cron-Policy und Writer-Wartezeit/Timeout.
|
||||
|
||||
**Serverabnahme steht separat aus:** echte Rocky-Linux-10-Umgebung, SELinux-/ACL-Verhalten auf den verwendeten Dateisystemen, installierte Nextcloud-/Gitea-Versionen, vollständige Writer-/Pfadliste, Berechtigungen des echten DB-Backupaccounts, tatsächlicher OneDrive-Upload großer Archive, Laufzeit/Speicherbedarf und fachliche Restore-Probe. Es wurde kein Produktivbackup ausgeführt und keine Serverinstallation verändert.
|
||||
Reference in new issue
Block a user