Restart dashboard systemd unit after hermes update if one is installed

[rahlquist]

Problem

hermes update only auto-restarts hermes-gateway* systemd units. The web dashboard is killed by PID at the end of the update and never relaunched, so users who run the dashboard as a systemd service (hermes-dashboard.service, per the dashboard docs / packaging) end up with a silently dead dashboard after every update.

Root cause confirmed in hermes_cli/main.py:

• the gateway restart block lists only hermes-gateway* units (line ~11184),
• _kill_stale_dashboard_processes() (line ~6428) SIGTERMs the dashboard PID and prints a manual relaunch hint, with an explicit comment that the dashboard "has no service manager".

Fix

Add _restart_dashboard_via_service_manager(). At the end of the update, instead of unconditionally PID-killing the dashboard, it:

1. Probes for an active hermes-dashboard* systemd unit in both --user and system scope (systemctl list-units hermes-dashboard*).
2. If found, restarts it via the same reset-failed -> restart (+ one retry) -> is-active poll path already used for gateways, including the non-interactive sudo -n privilege probe so it cannot hang on a polkit prompt.
3. Falls back to the existing PID-kill (_kill_stale_dashboard_processes) only when no systemd unit owns the dashboard — i.e. the upstream default (no service manager) behavior is fully preserved.

Scope note: systemd-only. There is no standardized upstream launchd label for the dashboard (only the gateway has get_launchd_label()), so adding launchd guesswork would be speculative. Linux systemd units are the real, reproducible case.

Verification

• Patch generated against HEAD 75be8fb46 (live install) and against the fresh fork clone (32a9f2a); git apply --check passes in both.
• Edited module ast.parse-valid.
• Local unit workaround (Restart=always) confirmed working independently on the reporter's machine.

Test plan

• On a machine with hermes-dashboard.service active: hermes update restarts it (visible in systemctl --user status hermes-dashboard).
• On a machine without a dashboard unit: behavior unchanged (legacy PID-kill + manual relaunch hint).

[alt-glitch]

This was generated by AI during triage.

Related: #40616 and #39166 address the same dashboard-update/systemd lifecycle. This patch uses active-unit discovery and restart-before-PID cleanup, while #40616 validates service ExecStart after cleanup; maintainer direction is needed on the intended service-management policy.

[rahlquist]

Apologies for the duplication

[rahlquist]

Closing as a duplicate of #40616 and #39166, which cover the same hermes update dashboard systemd restart. My local instance is already handled by Restart=always on the dashboard unit, so there is no personal need remaining. Apologies for the noise — maintainers should take whichever approach they prefer from the existing PRs.