fix(update): kill stale dashboards instead of warning by teknium1 · Pull Request #17832 · NousResearch/hermes-agent

teknium1 · 2026-04-30T08:25:59Z

Summary

hermes update now stops any running hermes dashboard processes at the end of the update instead of just warning the user to restart them.

The old warning was routinely ignored, leaving users with a stale Python backend serving a freshly-updated JS bundle → silent auth-header mismatches, 401s on every API call, empty dashboards.

The dashboard has no service manager and no saved launch args, so we can't auto-restart it — but stopping it is strictly better than leaving the broken backend alive. A restart hint is printed.

Changes

hermes_cli/main.py: split detection (_find_stale_dashboard_pids) from action (_kill_stale_dashboard_processes). POSIX: SIGTERM → 3s grace → SIGKILL. Windows: taskkill /F. Old _warn_stale_dashboard_processes kept as back-compat alias.
tests/hermes_cli/test_update_stale_dashboard.py: rewrote around the new semantics. Covers SIGTERM graceful exit, SIGKILL fallback for survivors, PermissionError reporting, already-gone-PID handling, Windows taskkill path including failure reporting, plus the preserved [Bug]: UnicodeDecodeError and AttributeError in Windows gateway process scanning #17049 wmic encoding regression tests.

Detection logic itself is unchanged (same ps / wmic scan, same greedy-match guards from #16872, same #17049 wmic UnicodeDecodeError fix).

Validation

	Before	After
Stale dashboard after `hermes update`	Still running old backend, serves stale API	SIGTERM'd, user restarts on demand
Survivor of SIGTERM grace window	n/a	SIGKILL
No dashboard running	No-op	No-op
`ps` / `wmic` missing or timing out	Silent skip	Silent skip (unchanged)
Test count	11	19 (all pass, `scripts/run_tests.sh`)

E2E: spawned exec -a 'hermes dashboard …' sleep 300, called _kill_stale_dashboard_processes(), confirmed SIGTERM exit (-15) and empty post-scan.

`hermes update` previously just printed a warning when it detected a running `hermes dashboard` process from the previous version, telling the user to kill and restart it themselves. In practice dashboards get started and forgotten, so the warning was routinely ignored and users ended up with a silent frontend/backend mismatch (new JS bundle served against the old in-memory Python backend, e.g. new auth headers the old code doesn't recognise → every API call 401s). The dashboard has no service manager, no PID file, and we don't record the original launch args (--host, --port, --insecure, --tui, --no-open) so we can't auto-restart it. But we CAN stop it, which is what the user wants — the failure mode when the stale process is left alive is worse than the dashboard just being down. - POSIX: SIGTERM, poll for ~3s, SIGKILL any survivors. - Windows: `taskkill /PID <pid> /F`. - Print each PID's outcome plus a one-line restart hint. - Detection logic is unchanged (same ps / wmic scan, same guards against the `pgrep -f` greedy-match trap from #16872 and the #17049 wmic UnicodeDecodeError fix). Also split the old monolithic `_warn_stale_dashboard_processes` into `_find_stale_dashboard_pids` (scan) + `_kill_stale_dashboard_processes` (kill), keeping the old name as an alias so any external callers still work. E2E verified: spawned a fake `hermes dashboard` cmdline via `exec -a 'hermes dashboard …' sleep 300`, ran `_kill_stale_dashboard_processes()`, confirmed SIGTERM exit (-15) and that a post-scan returns an empty PID list.

`hermes dashboard` is a long-lived foreground server that users often start and forget about, sometimes in a shell they've since closed. We didn't have a way to stop it — users had to find the PID manually. Adds two lifecycle flags that reuse the same detection + termination path the post-`hermes update` cleanup (PR #17832) uses: hermes dashboard --status List running hermes dashboard processes with PID + cmdline. Exit 0, informational. hermes dashboard --stop Terminate all running dashboards (3s grace then force-kill survivors). Exit 0 if none remain, 1 if any couldn't be stopped. Windows uses `taskkill /F` as before. Both flags short-circuit before any fastapi/uvicorn import so they work even on installations where the dashboard extras aren't installed — useful when you're cleaning up after uninstalling. The kill helper gained an optional `reason=...` param so the output reads "(requested via --stop)" instead of the post-update-specific "running backend no longer matches the updated frontend" wording. E2E: `hermes dashboard --status` with nothing running prints the empty message; with a fake `hermes dashboard ...` cmdline spawned via `exec -a`, `--status` lists it, `--stop` terminates it (exit -15), and a follow-up `--status` returns empty.

…n reload (#17881) Six tests in this file failed in CI (-n auto) after #17832 landed because other tests on the same xdist worker reload hermes_cli.main: tests/hermes_cli/test_env_loader.py:85-86 sys.modules.pop('hermes_cli.main', None) importlib.import_module('hermes_cli.main') tests/hermes_cli/test_skills_subparser.py:24-25 del sys.modules['hermes_cli.main'] When either ran first on a worker, our top-of-file 'from hermes_cli.main import _kill_stale_dashboard_processes' captured a stale function object whose __globals__ points at the old module dict. patch('hermes_cli.main._find_stale_dashboard_pids', ...) then patched the new module, but the stale function resolved the dependency via its stale __globals__, so every patch became a no-op: pids=[] → early return → no signals, no output, assertions failed. Fix: add an autouse fixture that rebinds the three module-level names to whatever is currently live in sys.modules['hermes_cli.main'] before each test runs. The pollutants in the other two files are load-bearing for their own tests, so fixing it on the consumer side is correct. Repro: pytest tests/hermes_cli/test_env_loader.py tests/hermes_cli/test_update_stale_dashboard.py

…esearch#17832) `hermes update` previously just printed a warning when it detected a running `hermes dashboard` process from the previous version, telling the user to kill and restart it themselves. In practice dashboards get started and forgotten, so the warning was routinely ignored and users ended up with a silent frontend/backend mismatch (new JS bundle served against the old in-memory Python backend, e.g. new auth headers the old code doesn't recognise → every API call 401s). The dashboard has no service manager, no PID file, and we don't record the original launch args (--host, --port, --insecure, --tui, --no-open) so we can't auto-restart it. But we CAN stop it, which is what the user wants — the failure mode when the stale process is left alive is worse than the dashboard just being down. - POSIX: SIGTERM, poll for ~3s, SIGKILL any survivors. - Windows: `taskkill /PID <pid> /F`. - Print each PID's outcome plus a one-line restart hint. - Detection logic is unchanged (same ps / wmic scan, same guards against the `pgrep -f` greedy-match trap from NousResearch#16872 and the NousResearch#17049 wmic UnicodeDecodeError fix). Also split the old monolithic `_warn_stale_dashboard_processes` into `_find_stale_dashboard_pids` (scan) + `_kill_stale_dashboard_processes` (kill), keeping the old name as an alias so any external callers still work. E2E verified: spawned a fake `hermes dashboard` cmdline via `exec -a 'hermes dashboard …' sleep 300`, ran `_kill_stale_dashboard_processes()`, confirmed SIGTERM exit (-15) and that a post-scan returns an empty PID list.

…n reload (NousResearch#17881) Six tests in this file failed in CI (-n auto) after NousResearch#17832 landed because other tests on the same xdist worker reload hermes_cli.main: tests/hermes_cli/test_env_loader.py:85-86 sys.modules.pop('hermes_cli.main', None) importlib.import_module('hermes_cli.main') tests/hermes_cli/test_skills_subparser.py:24-25 del sys.modules['hermes_cli.main'] When either ran first on a worker, our top-of-file 'from hermes_cli.main import _kill_stale_dashboard_processes' captured a stale function object whose __globals__ points at the old module dict. patch('hermes_cli.main._find_stale_dashboard_pids', ...) then patched the new module, but the stale function resolved the dependency via its stale __globals__, so every patch became a no-op: pids=[] → early return → no signals, no output, assertions failed. Fix: add an autouse fixture that rebinds the three module-level names to whatever is currently live in sys.modules['hermes_cli.main'] before each test runs. The pollutants in the other two files are load-bearing for their own tests, so fixing it on the consumer side is correct. Repro: pytest tests/hermes_cli/test_env_loader.py tests/hermes_cli/test_update_stale_dashboard.py

…esearch#17832) `hermes update` previously just printed a warning when it detected a running `hermes dashboard` process from the previous version, telling the user to kill and restart it themselves. In practice dashboards get started and forgotten, so the warning was routinely ignored and users ended up with a silent frontend/backend mismatch (new JS bundle served against the old in-memory Python backend, e.g. new auth headers the old code doesn't recognise → every API call 401s). The dashboard has no service manager, no PID file, and we don't record the original launch args (--host, --port, --insecure, --tui, --no-open) so we can't auto-restart it. But we CAN stop it, which is what the user wants — the failure mode when the stale process is left alive is worse than the dashboard just being down. - POSIX: SIGTERM, poll for ~3s, SIGKILL any survivors. - Windows: `taskkill /PID <pid> /F`. - Print each PID's outcome plus a one-line restart hint. - Detection logic is unchanged (same ps / wmic scan, same guards against the `pgrep -f` greedy-match trap from NousResearch#16872 and the NousResearch#17049 wmic UnicodeDecodeError fix). Also split the old monolithic `_warn_stale_dashboard_processes` into `_find_stale_dashboard_pids` (scan) + `_kill_stale_dashboard_processes` (kill), keeping the old name as an alias so any external callers still work. E2E verified: spawned a fake `hermes dashboard` cmdline via `exec -a 'hermes dashboard …' sleep 300`, ran `_kill_stale_dashboard_processes()`, confirmed SIGTERM exit (-15) and that a post-scan returns an empty PID list.

`hermes dashboard` is a long-lived foreground server that users often start and forget about, sometimes in a shell they've since closed. We didn't have a way to stop it — users had to find the PID manually. Adds two lifecycle flags that reuse the same detection + termination path the post-`hermes update` cleanup (PR NousResearch#17832) uses: hermes dashboard --status List running hermes dashboard processes with PID + cmdline. Exit 0, informational. hermes dashboard --stop Terminate all running dashboards (3s grace then force-kill survivors). Exit 0 if none remain, 1 if any couldn't be stopped. Windows uses `taskkill /F` as before. Both flags short-circuit before any fastapi/uvicorn import so they work even on installations where the dashboard extras aren't installed — useful when you're cleaning up after uninstalling. The kill helper gained an optional `reason=...` param so the output reads "(requested via --stop)" instead of the post-update-specific "running backend no longer matches the updated frontend" wording. E2E: `hermes dashboard --status` with nothing running prints the empty message; with a fake `hermes dashboard ...` cmdline spawned via `exec -a`, `--status` lists it, `--stop` terminates it (exit -15), and a follow-up `--status` returns empty.