diff --git a/README.md b/README.md index ba676f7..2a866d6 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Reproduzierbares Benutzer-Deployment für Hermes Agent auf Arch Linux mit: - optionalem CUDA-Build von llama-server, llama-cli und llama-bench - Qwen-/RTX-3080-Profilen mit prüfbarem Wechsel und Rückweg -Stand: 2026-10-12. Für deine **bestehende Workstation** zuerst +Stand: 2026-10-21. Für deine **bestehende Workstation** zuerst [`docs/WORKSTATION.md`](docs/WORKSTATION.md) lesen. Der Schnellstart unten ist für eine neue Maschine. Hardware-Leistungsgewinne sind noch nicht auf deiner GPU gemessen; die kurze Funktions- und VRAM-Abnahme vom 12.10.2026 ist in @@ -150,7 +150,7 @@ Update-Lock und löst bei Backend-HTTP-Timeouts keine Inferenz-Neustarts mehr au 1. exklusives Lock und Prüfung auf lokale Änderungen 2. `origin/main`-Fetch mit begrenzten Retries und letztem HTTP/1.1-Fallback -3. schneller Abschluss ohne Backup, wenn kein Update vorliegt +3. schneller Abschluss ohne Backup, wenn Checkout und gefetchter Branch identisch sind 4. komprimiertes Backup vor jeder Änderung 5. Stoppen des Gateways und Aufruf von `hermes update` 6. einmaliger Retry bei eindeutig transientem Fetch-Fehler @@ -159,9 +159,17 @@ Update-Lock und löst bei Backend-HTTP-Timeouts keine Inferenz-Neustarts mehr au 9. separater llama.cpp-Healthcheck ohne unsinnigen Hermes-Rollback 10. Aufbewahrung der drei neuesten Hermes-Backups +Den Zielstand wählt `hermes update` anhand des konfigurierten Update-Kanals. +Bei Stable kann der Checkout bereits aktuell sein, obwohl `origin/main` weiter +ist. Ein unveränderter Commit bei Updater-Exitcode 0 und gesundem Gateway gilt +deshalb als Erfolg. Dabei können Backup und Gateway-Neustart trotzdem stattfinden. +Ein fehlgeschlagener Updater bei unverändertem Commit bleibt ein Fehler. + Ein Fehler von Telegram oder Signal kann den Updateprozess niemals fehlschlagen lassen. Detaillierte Zwischenstände landen im Journal; nur zusammengefasste -Ergebnisse werden versendet. +Ergebnisse werden versendet. Abschlussmeldungen stehen auch direkt im Journal +von `hermes-stack-hermes-update.service`. Diagnose, gezielte Installation und +Prüfung sind in [HERMES_UPDATE.md](docs/HERMES_UPDATE.md) beschrieben. ## Bedienung diff --git a/docs/HERMES_UPDATE.md b/docs/HERMES_UPDATE.md new file mode 100644 index 0000000..1aecc03 --- /dev/null +++ b/docs/HERMES_UPDATE.md @@ -0,0 +1,69 @@ +# Hermes-Update betreiben und prüfen + +## Bereits aktuelle Stable-Version + +Der Updater prüft zunächst den konfigurierten Remote-Branch (standardmäßig +`origin/main`). Den tatsächlichen Zielstand wählt anschließend `hermes update` +anhand des Hermes-Update-Kanals. Bei Stable kann der installierte Release-Commit +aktuell sein, obwohl auf `main` neuere Entwicklungscommits liegen. + +Bis zur Korrektur vom 21.10.2026 endete dieser Fall trotz `Already up to date!` +und Updater-Exitcode 0 mit einem fehlgeschlagenen Wartungsdienst. Das Skript +forderte fälschlich einen Commitwechsel. Jetzt endet ein erfolgreicher Updater +mit unverändertem Commit nach den Konfigurations- und Gateway-Prüfungen +erfolgreich. Der Kanal wird durch diese Korrektur nicht geändert. + +Ein fehlgeschlagener Updater bei unverändertem Commit liefert weiterhin Exitcode +1. Ein ungesunder Gateway löst weiterhin den vorhandenen Rollback aus. Der +separate llama-Endpunkt wird unabhängig geprüft; dessen Ausfall führt nicht zu +einem Hermes-Rollback. + +## Nur den korrigierten Wrapper installieren + +Im Repository-Verzeichnis ausführen, wenn gerade kein Update läuft. Vorher +laufende Hermes-Aufgaben beenden lassen. Diese gezielte Installation ersetzt nur +den Wrapper; `./install.sh` installiert dagegen alle versionierten Wrapper/Units. + +```bash +make test +backup_dir="$(mktemp -d "$HOME/.local/state/hermes-update-wrapper.XXXXXXXX")" +cp -p ~/.local/libexec/hermes-stack-hermes-update "$backup_dir/" +printf 'Wrapper-Sicherung: %s\n' "$backup_dir" +install -m 0755 libexec/hermes-stack-hermes-update \ + ~/.local/libexec/hermes-stack-hermes-update +cmp libexec/hermes-stack-hermes-update \ + ~/.local/libexec/hermes-stack-hermes-update +``` + +Die Unit bleibt unverändert; dafür ist kein `daemon-reload` erforderlich. +Die vorherige Wrapper-Version liegt im ausgegebenen bzw. in `$backup_dir` +gespeicherten Sicherungsverzeichnis. Bei Bedarf dieselbe Datei mit `install +-m 0755` zurückkopieren, während kein Update läuft. + +## Manueller Lauf und Diagnose + +Der Lauf kann den Gateway kurz stoppen und neu starten. Er erzeugt nach dem +Remote-Vergleich gegebenenfalls auch dann ein Backup, wenn Stable bereits aktuell +ist. Standardmäßig werden die drei neuesten Hermes-Backups behalten. + +```bash +systemctl --user start hermes-stack-hermes-update.service +systemctl --user show hermes-stack-hermes-update.service \ + -p ActiveState -p SubState -p Result -p ExecMainStatus +systemctl --user is-active hermes-gateway.service +journalctl --user -u hermes-stack-hermes-update.service -n 100 --no-pager +journalctl --user -t hermes-stack-maintenance -n 100 --no-pager +``` + +Erwartet: `Result=success`, `ExecMainStatus=0` und ein aktiver Gateway. Als +`Type=oneshot` ist der Update-Dienst nach erfolgreichem Abschluss selbst wieder +`inactive/dead`. Die Meldung `Hermes ist im konfigurierten Update-Kanal bereits +aktuell` bestätigt den erfolgreichen Lauf ohne Versionswechsel. + +Updater-Ausgaben liegen zusätzlich unter +`~/.local/state/hermes-stack-maintenance/hermes-update-*.log`. +Wrapper-Abschlussmeldungen stehen im Dienstjournal; die Benachrichtigung schreibt +zusätzlich unter dem Tag `hermes-stack-maintenance`. + +Die Abnahme auf Archwork und ihre Prüfgrenzen stehen in +[VALIDATION.md](VALIDATION.md). diff --git a/docs/VALIDATION.md b/docs/VALIDATION.md index cf376fc..2c88fac 100644 --- a/docs/VALIDATION.md +++ b/docs/VALIDATION.md @@ -1,3 +1,20 @@ +# Validierung vom 2026-10-21 + +- `make test`: Syntax- und Secret-Musterprüfung sowie **31 Funktionstests + bestanden** (26 vorhandene Tests und fünf neue Updater-Regressionstests). +- Neue isolierte Tests: unveränderter Stable-Commit bei neuerem `main`, + fehlgeschlagener Updater ohne Commitwechsel, erfolgreicher Commitwechsel, + Commitwechsel mit Updater-Restartwarnung und Gateway-Rollback. + Externe Programme werden simuliert; kein echtes Netzwerk oder systemd darin. +- `git diff --check`: erfolgreich. ShellCheck ist lokal nicht installiert. +- Korrigierter Wrapper auf Archwork installiert und bytegleich geprüft. +- Echter Update-Dienstlauf am 21.10.2026, 16:26 MESZ: Stable v0.22.3 blieb auf + Commit `5b147ab036d6d19131bff8d20701b5001eab844a`; Abschluss nach rund 47 Sekunden + mit `Result=success` und `ExecMainStatus=0`. Gateway danach `active/running`. + Die neue Erfolgsmeldung erschien im Journal des Update-Dienstes. +- Ein echter Versionswechsel und ein echter Rollback wurden bei dieser Abnahme + nicht ausgelöst. Ein vollständiger Installer-Lauf wurde nicht durchgeführt. + # Validierung vom 2026-10-12 - `make test`: Shell-Syntaxprüfung, Secret-Mustercheck und **26 isolierte diff --git a/docs/WORKSTATION.md b/docs/WORKSTATION.md index 33c7ab1..8adb525 100644 --- a/docs/WORKSTATION.md +++ b/docs/WORKSTATION.md @@ -147,3 +147,16 @@ Repo-Dateien wurden danach aufgenommen und getestet, aber nicht erneut über `install.sh` auf die Workstation ausgerollt. Der aktuelle Betrieb bleibt bei den bereits geprüften Einstellungen. Details zur Übertragung und zu bestehenden Units/Drop-ins stehen in [RTX3080.md](RTX3080.md). + +## Hermes-Update-Korrektur vom 2026-10-21 + +Der korrigierte `hermes-stack-hermes-update` ist gezielt auf der Workstation +installiert und mit der Repository-Datei bytegleich geprüft. Der echte +Dienstlauf mit bereits aktuellem Stable v0.22.3 endete erfolgreich +(`Result=success`, `ExecMainStatus=0`); der Gateway war danach `active/running`. +Abschlussmeldungen erscheinen jetzt direkt im Dienstjournal. + +Vorherige Wrapper-Version: +`~/.local/libexec/hermes-stack-hermes-update.before-noop-fix-20261021`. +Ein vollständiger Installer-Lauf war für diese Korrektur nicht erforderlich. +Betrieb und Fehlerdiagnose: [HERMES_UPDATE.md](HERMES_UPDATE.md).