Files
hermes-arch-stack/docs/HERMES_UPDATE.md
T

3.2 KiB

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.

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.

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.