Fix systemd oneshot upgrade handoff deadlock

UPDATE_ANLEITUNG.md

@@ -24,7 +24,8 @@ Backups mit zeitweiliger Unterbrechung der konfigurierten Anwendungen.
 5. Crypt-Konfiguration und DB-Dateien prüfen; vorhandene Schlüssel/Passwörter erhalten.
 6. Vorprüfung mit geschützten Kopien durchführen. Bei Fehlern bleibt das installierte
    Paket samt Anwendungskonfiguration und Timer unverändert.
-7. Einen von SSH unabhängigen systemd-Auftrag `app-backup-upgrade.service` starten.
+7. Einen von SSH unabhängigen systemd-Auftrag `app-backup-upgrade.service` mit
+   `--no-block` einreihen und die Sperren an ihn übergeben.
 8. Backup-Timer stoppen, Paket mit Rollback-Inventar installieren, Konfiguration
    atomar übernehmen und Rechte der aktiven root-eigenen Zugangsdaten korrigieren.
 9. Vollständiges Backup ohne lokale/Remote-Retention durchführen. Anschließend den
@@ -37,7 +38,7 @@ Remote-Prüflauf belegt Archivlesbarkeit, ersetzt aber keinen fachlichen Test-Re
 ## Verlauf und Ergebnis
 
 ```bash
-sudo journalctl -fu app-backup-upgrade.service
+sudo journalctl -fu app-backup-upgrade.service --no-pager
 ```
 
 Der Starter nennt außerdem den **konkreten** Ergebnisordner:
@@ -47,9 +48,24 @@ sudo cat /var/backups/app-backup-upgrade-XXXXXXXX/result.txt
 sudo less /var/backups/app-backup-upgrade-XXXXXXXX/update.log
 ```
 
-Erwartet wird `SUCCESS`. Solange `RUNNING` steht, nicht parallel erneut starten.
-Nach Ende verschwindet die kurzlebige systemd-Unit; Log und Ergebnis bleiben erhalten.
-Bei `QUEUED` wurde der Auftrag übergeben und wartet auf den Start.
+Erwartet wird `SUCCESS`. Bei `QUEUED` oder `RUNNING` nicht parallel erneut starten.
+`QUEUED` bedeutet, dass der Auftrag zur Übergabe vorbereitet wurde und noch kein
+Worker den Start bestätigt hat. Ein erfolgreicher Starter bestätigt nur die
+Annahme durch systemd; Installation und Backup können anschließend noch scheitern.
+Nach Ende verschwindet die kurzlebige systemd-Unit durch `--collect` auch bei
+Fehlern. `Unit ... could not be found` ist daher kein Erfolgsnachweis und verhindert
+die Journalabfrage nicht. Log und Ergebnis bleiben erhalten. Diagnose ohne Pager:
+
+```bash
+sudo journalctl -u app-backup-upgrade.service -n 100 --no-pager -l
+sudo systemctl status app-backup-upgrade.service --no-pager -l
+```
+
+Bleibt `QUEUED` stehen, zuerst das Journal prüfen: Ein Fehler noch vor dem Start
+des Bash-Workers (z. B. ein nicht ausführbarer Paketpfad) kann noch nicht in
+`update.log` oder `result.txt` durch den Worker protokolliert werden. Ein späterer
+Sperr-Timeout erscheint dagegen in beiden Dateien. Nicht allein auf den Exit-Code
+von `systemd-run` vertrauen.
 `--foreground` führt den Vorgang stattdessen im aktuellen Terminal aus und ist
 für Tests/Diagnose gedacht; dabei besteht keine Absicherung gegen SSH-Abbruch.
 
@@ -107,6 +123,30 @@ bleiben erhalten; beim Aktivieren kann `Persistent=true` einen Lauf nachholen.
 
 ## Fehler und Rückweg
 
+### Startfehler nach genau 60 Sekunden bei älteren Paketen
+
+Die Pakete `8e6c9a058fa9` und `56fbcdad74f4` enthielten einen Fehler in der
+systemd-Übergabe: Der Starter hielt die Update-Sperre und wartete synchron auf
+den Abschluss des Startauftrags einer `Type=oneshot`-Unit. Dieser Startauftrag
+endet erst mit dem Worker; der Worker wartete aber selbst auf die Sperre des
+Starters. Nach 60 Sekunden brach seine Sperranforderung ab, noch vor Installation
+und Timer-Stopp. In diesem Ablauf ist kein Rollback erforderlich. Der ursprüngliche
+Worker hatte vor dem Sperrwarten noch kein eigenes Log eingerichtet, daher konnte
+die Fehlermeldung auf den systemd-Exit-Code beschränkt bleiben.
+
+Das korrigierte Paket verwendet `systemd-run --no-block` und gibt zuerst die
+Backup-Sperre, dann die Update-Sperre frei. Eine fehlgeschlagene Übergabe entzieht
+auch einem möglicherweise schon eingereihten Worker die Freigabe. Die Sperren
+bleiben als Schutz vor parallelen Backups/Updates erhalten. Erneut das **neue**
+Paket starten; weder Sperrdateien löschen noch alte Worker manuell nachstarten.
+
+Das Verhalten von `--no-block` und `--collect` ist in der
+[systemd-Dokumentation](https://github.com/systemd/systemd/blob/v256/man/systemd-run.xml)
+beschrieben, der Startabschluss von `oneshot` in
+[systemd.service](https://github.com/systemd/systemd/blob/v256/man/systemd.service.xml).
+
+### Fehlende Mailablage und erneuter Start
+
 Ein Abbruch `Missing source: /var/vmail` bei der **Vorprüfung**, wie beim Paket
 `8e6c9a058fa9`, erfordert kein Rollback. Mit dem korrigierten Paket erneut starten
 und die Mailablage klären. Die bisherige Konfiguration und der Timer sind erhalten;
@@ -134,6 +174,8 @@ Vorlage vollständig kopiert, sofern es auf demselben Dateisystem liegt und kein
 Verweis auf eine externe Ablage ist. Weitere Benutzer müssen in `MAIL_HOME_DIRS`
 stehen; das Vorhandensein eines einzelnen Postfachs belegt nicht deren Abdeckung.
 
+### Fehler nach Installationsbeginn
+
 Bei einem Fehler nach Beginn der Installation bleibt der Backup-Timer gestoppt.
 Es erfolgt kein automatisches Zurücksetzen über möglicherweise noch laufende oder
 teilweise wiederhergestellte Anwendungen. Logs und gegebenenfalls
@@ -165,8 +207,12 @@ Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal bez
 
 ## Verifikation der Lieferung
 
-34 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
+37 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
 Die Tests enthalten echte MariaDB-Dumps/Imports und lokale rclone-Crypt-Roundtrips;
-systemd/occ und die systemd-run-Übergabe sind simuliert. Die tatsächliche
+systemd/occ und die systemd-run-Übergabe sind simuliert. Das Übergabemodell
+berücksichtigt jetzt das Warten auf den oneshot-Startauftrag: Der Regressionstest
+scheiterte mit dem alten Code und war nach dem Fix erfolgreich. Geprüft sind auch
+abgewiesene Übergaben, eingereihte Worker trotz fehlgeschlagener Antwort und
+persistente Fehlerprotokolle bei belegter Update-Sperre. Die tatsächliche
 Server-/OneDrive-Prüfung erfolgt beim ersten Paketlauf. Ein fachlicher Restore
 auf einem separaten Testsystem bleibt erforderlich.