Was ist genau passiert?
Meta-Description (Vorschlag): Die Hermes WebUI verweigert nach einem Agent-Update den Dienst? Warum sudo systemctl restart hermes-webui ins Leere läuft – und welcher Ein-Zeiler das Problem wirklich löst.
Wer den Hermes Agent lokal betreibt und die Weboberfläche im Browser nutzt, kennt das Szenario vermutlich: Man aktualisiert den Agent, wechselt zurück in den geöffneten Browser-Tab, klickt auf eine beliebige Aktion – und statt eines Ergebnisses erscheint diese Meldung:
Hermes Agent was updated while Hermes WebUI was running. Restart Hermes WebUI before retrying this action.
Die Meldung sagt ziemlich genau, was zu tun ist. Trotzdem scheitern die naheliegenden Neustart-Kommandos, und man sitzt schnell zehn Minuten lang vor einem Problem, das eine einzige Zeile löst.
Die Kurzfassung
systemctl --user restart hermes-webui
Kein sudo. Das ist der entscheidende Punkt.
Warum die Meldung überhaupt erscheint
Es handelt sich nicht um einen Fehler im klassischen Sinn, sondern um eine bewusst eingebaute Schutzmaßnahme wenn diese Meldung auftaucht: „Hermes Agent was updated while Hermes WebUI was running. Restart Hermes WebUI before retrying this action“
Die WebUI ist ein eigener, langlebiger Prozess. Beim Start lädt sie die Module des Hermes Agent in den Arbeitsspeicher und behält diese Version dort, solange sie läuft. Wird der Agent anschließend auf der Festplatte aktualisiert, passiert im laufenden Prozess zunächst gar nichts: Der Code im Speicher ist eingefroren, der Code auf der Platte ist neu.
Genau diese Diskrepanz erkennt Hermes und blockiert weitere Aktionen. Das ist sinnvoll, denn die Alternative wäre deutlich unangenehmer: eine Oberfläche, die alte und neue Codepfade mischt, Aufrufe mit veränderten Signaturen absetzt oder mit einem migrierten Datenbankschema arbeitet, das sie noch gar nicht kennt. Ein sauberer Abbruch mit klarer Handlungsanweisung ist die deutlich bessere Variante.
Merksatz: Ein Update des Agents wirkt erst nach einem Neustart der WebUI.
Warum sudo systemctl restart hermes-webui nicht funktioniert
Hier liegt die eigentliche Stolperfalle. Typische Reaktionen des Systems sind:
Failed to restart hermes-webui.service: Unit hermes-webui.service not found.
oder ein Neustart, der zwar quittiert wird, aber am Zustand im Browser nichts ändert.
Der Grund: systemd verwaltet zwei getrennte Ebenen.
- System-Ebene – Dienste, die beim Booten als root starten, unabhängig von einer Anmeldung. Angesprochen mit
systemctlbzw.sudo systemctl. - User-Ebene – Dienste, die im Kontext eines konkreten Benutzers laufen. Angesprochen mit
systemctl --user.
Eine lokale Hermes-Installation liegt in der Regel im Home-Verzeichnis (etwa unter ~/.hermes), greift auf benutzereigene Konfiguration, Modelle und Datenbanken zu und wird deshalb sinnvollerweise als User-Unit betrieben.
Und jetzt der Punkt, der die Sache verwirrend macht: sudo wechselt nicht nur die Rechte, sondern auch den Benutzerkontext. sudo systemctl --user restart hermes-webui fragt folglich den Session-Bus von root ab – und dort existiert die Unit schlicht nicht. Das sudo gehört an dieser Stelle also ersatzlos gestrichen.
Gleiches gilt für Versuche wie systemctl restart hermes: Wenn es keine System-Unit dieses Namens gibt, kann sie auch nicht neu gestartet werden.
Diagnose: Wie läuft die WebUI bei mir eigentlich?
Falls der Ein-Zeiler oben nichts bewirkt, lohnt es sich, den tatsächlichen Zustand zu prüfen. Diese vier Kommandos klären die Lage schnell:
# 1. Existiert eine User-Unit?
systemctl --user list-units --all | grep -i hermes
# 2. Existiert eine System-Unit?
systemctl list-units --all --type=service | grep -i hermes
# 3. Läuft der Prozess vielleicht ganz ohne systemd (Shell, tmux, screen)?
ps aux | grep -i hermes | grep -v grep
# 4. Welche PID belegt den WebUI-Port? (Port ggf. anpassen)
sudo ss -tulpn | grep -E '8000|8080|7860'
Besonders aussagekräftig ist Kommando 4: Der Prozess, der den Port hält, ist genau der Prozess, der neu gestartet werden muss – egal, wie er ursprünglich gestartet wurde.
Je nach Befund gilt dann:
- User-Unit:
systemctl --user restart hermes-webui - System-Unit:
sudo systemctl restart hermes-webui - Manuell gestartet: Prozess mit
kill <PID>beenden, mitps auxdas Ende verifizieren und anschließend den gewohnten Startbefehl erneut ausführen - Container:
docker restart <container-name>
Wenn die Meldung nach dem Neustart bestehen bleibt
In den allermeisten Fällen ist nach dem Neustart Ruhe. Bleibt die Meldung, gibt es zwei typische Ursachen:
Der alte Prozess lebt noch. Der Neustart ist fehlgeschlagen, der Port ist weiterhin von der alten Instanz belegt, und der Browser spricht unverändert mit dem Prozess von vorhin. Prüfen mit:
systemctl --user status hermes-webui
journalctl --user -u hermes-webui -n 50 --no-pager
Der Browser hält an einem alten Zustand fest. Ein Hard Reload (Strg + Shift + R) räumt hier auf, insbesondere bei offenen WebSocket-Verbindungen oder gecachten Frontend-Assets.
Nach einem Neustart des Rechners: Lingering beachten
Ein Nebeneffekt von User-Units, der gern für Verwirrung sorgt: Standardmäßig laufen sie nur, solange eine Sitzung des Benutzers besteht. Auf einem Server ohne dauerhaft angemeldeten Nutzer ist die WebUI nach einem Reboot damit schlicht weg.
Abhilfe schafft das sogenannte Lingering:
sudo loginctl enable-linger $USER
Damit startet die User-Unit auch ohne aktive Anmeldung – und die Oberfläche ist nach einem Neustart wieder erreichbar.
Fazit
Die Meldung ist kein Defekt, sondern ein bewusster Schutzmechanismus gegen einen inkonsistenten Zustand zwischen aktualisiertem Agent und noch laufender Oberfläche. Die Lösung besteht aus einem einzigen Kommando – man muss nur wissen, dass die WebUI als User-Dienst läuft und sudo hier aktiv im Weg steht:
systemctl --user restart hermes-webui
Wer den Agent regelmäßig aktualisiert, nimmt den Neustart am besten fest in die Update-Routine auf. Dann taucht die Meldung gar nicht erst auf.
Hier ein Artikel für die Anbindung von Hermes zu SSH – Artikel