hermes update does not detect or suggest restart for managed dashboard services

[BigDon86]

Summary

When running hermes update, the update process correctly detects a running dashboard whose backend no longer matches the updated frontend and stops the process. However, it has no awareness of whether the dashboard is managed by systemd (user or system service). It always prints the generic manual command hermes dashboard --port <port> instead of suggesting the appropriate systemctl --user restart (or systemctl restart) command.

In the reported case, the user-level service (hermes-dashboard.service) had a restart policy and automatically brought the dashboard back up, so there was no actual downtime. The issue is purely one of poor messaging and lack of integration with managed services.

Steps to Reproduce

1. Set up hermes-dashboard.service as a user service (~/.config/systemd/user/) with a restart policy because Hermes Desktop requires the dashboard backend.
2. Run hermes update.
3. The update stops the dashboard process and prints the generic manual restart command.
4. (In this case the service recovered automatically; in other configurations it may not.)

Expected Behavior

After stopping a dashboard process due to a version mismatch, the update script should:

• Detect whether the process is managed by a systemd service (user or system).
• Print the correct restart command (systemctl --user restart hermes-dashboard.service or equivalent).
• Optionally acknowledge that a managed service was detected.

Actual Behavior

The update always emits the same manual CLI instruction regardless of how the dashboard is being supervised. No attempt is made to discover or suggest the managed-service restart path.

Environment

• Hermes version: post-2026-06-06 update
• OS: WSL2 (Ubuntu) on Windows
• Hermes Desktop connected to WSL backend
• Dashboard running as user-level systemd service (hermes-dashboard.service)
• Service automatically restarted after the update killed the old process

Additional Context

• The service was intentionally created on 2026-06-05 to support Hermes Desktop.
• The backend/frontend mismatch protection logic is correct and desirable.
• The remaining gap is that the update process does not integrate with systemd-managed services when giving post-stop guidance.

Suggested Fix

In the update logic, after stopping a dashboard process:

1. Check for the existence of a corresponding systemd unit (both system and user scopes).
2. If found, emit the appropriate systemctl --user restart ... (or systemctl restart ...) command instead of (or in addition to) the generic hermes dashboard command.
3. Consider making the message context-aware based on how the dashboard was originally launched.

References

• Service file: /home/don/.config/systemd/user/hermes-dashboard.service

Severity: Low–Medium (Usability / Messaging)

[csoriano2718]

Real-world breakage from v0.17.0 update (multi-profile setup)

I run two profiles (personal on port 8643, redhat on port 8644) with hand-crafted dashboard systemd units — since there's no hermes dashboard install equivalent to hermes gateway install.

After updating to v0.17.0, three things broke simultaneously:

1. --insecure silently became a no-op

The June 2026 hardening made --insecure a no-op, so dashboards bound to 0.0.0.0 crash-loop with:

Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds, but no auth providers are registered.

No deprecation warning was emitted before the breaking change — the flag was accepted silently and then the dashboard refused to start.

2. No restart of running dashboard processes

The update stopped the old dashboard process (detected version mismatch) but printed only the generic hermes dashboard --port <port> command instead of detecting the systemd service and suggesting systemctl --user restart. The service's Restart=on-failure kicked in, but by then the new code had the --insecure breakage above, so it crash-looped.

3. env_float import error during transition

The Hermes Desktop app showed cannot import name 'env_float' from 'utils' — the running process had stale modules loaded from pre-update code. Only a full service restart resolved this.

What would help

• hermes update should detect managed dashboard services (systemd/launchd) and either restart them or print the correct restart command
• Breaking changes to flags like --insecure should emit a startup warning for at least one version before becoming fatal
• Ideally, hermes gateway install (or a new hermes dashboard install) should generate per-profile dashboard units alongside gateway units — the gateway already does this correctly via _profile_suffix()

[nameless43]

This seems to affect the gateway as well, not just dashboard-managed services.

After running hermes update on 2026-06-27, the update completed successfully but did not restart the running hermes-gateway process. The process had imported utils before newer code introduced/used env_float, so subsequent Telegram messages and cron jobs failed with:

ImportError: cannot import name 'env_float' from 'utils'

A /reset did not help because the stale state was in the long-lived gateway process, not the session. /restart fixed it immediately.

The update log for that run does not show the usual gateway restart sequence:

→ hermes-gateway: draining...
✓ Restarted hermes-gateway

Earlier update runs did include that restart sequence, so this looks like the same underlying class as this issue: hermes update should detect/restart managed long-lived Hermes processes reliably after code changes, or at minimum explicitly instruct the user to restart them.

This matters especially for Telegram/topic-based usage because once the gateway process is stale, session/topic recovery from mobile becomes misleading: users may try /reset, but only /restart can fix the process-level import cache.