hermes - 💡(How to fix) Fix [Bug]: hermes update attempts to stop other users’ hermes-dashboard services on multi-user hosts [3 pull requests]

On a multi-user Linux host, running hermes update as one Unix user scans the global process table for hermes dashboard processes and attempts to stop matching dashboards owned by other Unix users.

In my case, each user (john, marc, and tammy) has:

- a separate Unix account
- a separate Hermes install under /home/<user>/.hermes
- a separate hermes-gateway.service
- a separate hermes-dashboard.service
- a separate hermes-workspace.service

The dashboards are managed as systemd --user services, not ad-hoc background processes.

Despite that, updating one user’s Hermes install attempted to stop other users’ dashboard services.

This appears to come from the stale-dashboard cleanup path in hermes update, which seems to scan globally for dashboard processes instead of restricting itself to the current user.

1. Create multiple Unix users on the same Linux host.
2. Install Hermes separately for each user under their own home directories.
3. Run hermes dashboard for more than one user, preferably as systemd --user services.
4. Run hermes update as one of the users.
5. Observe that hermes update attempts to stop dashboard processes owned by other Unix users.

hermes update should only affect the current user’s Hermes processes and services.

At minimum, stale-dashboard detection should be scoped to the current UID.

Even better, if a per-user hermes-dashboard.service exists, only that user’s dashboard service should be restarted or replaced.

It should never attempt to stop dashboards owned by other Unix users.

Running hermes update as john produced:

text
✓ Update complete!
  → hermes-gateway: draining (up to 195s)...

  ✓ Restarted hermes-gateway

⟲ Stopping 2 dashboard process(es) (the running backend no longer matches the updated frontend)
    ✗ failed to stop PID 948: [Errno 1] Operation not permitted
    ✗ failed to stop PID 968: [Errno 1] Operation not permitted


Those PIDs were verified to belong to other users:

text
PID USER  UID  PPID CMD
948 marc  1002 848  /home/marc/.hermes/hermes-agent/venv/bin/python3 /home/marc/.hermes/hermes-agent/venv/bin/hermes dashboard --host 100.89.26.65 --port 9120 --no-open --insecure
968 tammy 1003 844  /home/tammy/.hermes/hermes-agent/venv/bin/python3 /home/tammy/.hermes/hermes-agent/venv/bin/hermes dashboard --host 100.89.26.65 --port 9121 --no-open --insecure


These were confirmed to be user systemd services via cgroups:

text
PID 948 -> /user.slice/user-1002.slice/[email protected]/app.slice/hermes-dashboard.service
PID 968 -> /user.slice/user-1003.slice/[email protected]/app.slice/hermes-dashboard.service


All three users have separate dashboard service files:

text
/home/john/.config/systemd/user/hermes-dashboard.service
/home/marc/.config/systemd/user/hermes-dashboard.service
/home/tammy/.config/systemd/user/hermes-dashboard.service


I also confirmed this was not specific to john:

- running hermes update as marc stopped marc’s dashboard and also attempted to stop tammy’s dashboard
- running hermes update as tammy then stopped only tammy’s dashboard, because marc’s had already been stopped

So this appears to be a general cross-user process selection bug on multi-user hosts.

Report       https://paste.rs/XQfvX
  agent.log    https://paste.rs/9UrT9
  gateway.log  https://paste.rs/GpLNL

    version:          0.15.1 (2026.5.29) [6f6eb871]
    os:               Linux 6.12.90+deb13.1-amd64 x86_64
    python:           3.11.15
    openai_sdk:       2.24.0
    profile:          default
    hermes_home:      ~/.hermes
    model:            gpt-5.4
    provider:         openai-codex
    terminal:         local
    
    features:
      toolsets:           hermes-cli
      mcp_servers:        0
      memory_provider:    holographic
      gateway:            running (systemd (user), pid 721513)
      platforms:          discord
      cron_jobs:          0
      skills:             93

Scope stale dashboard detection to the current Unix user instead of scanning the global process table without ownership filtering.

More specifically:

1. Restrict stale-dashboard discovery to processes owned by the current UID.
   - On Linux/macOS, _find_stale_dashboard_pids() currently scans ps -A -o pid=,command= and matches command lines.
   - That should instead either:
     - query only the current user’s processes, or
     - collect PID + UID and discard any process whose owner does not match os.getuid().

2. Also scope matches to the current Hermes install when possible.
   - If the command line or executable path can be resolved, prefer only matching dashboards launched from the current user’s Hermes home / venv path.
   - This provides a second safety boundary beyond UID filtering.

3. If a per-user hermes-dashboard.service exists, prefer restarting or replacing that service rather than killing arbitrary matching processes.
   - On hosts using systemd --user, the dashboard is not an unmanaged orphan process.
   - Service-aware handling would be safer and more consistent than global process killing.

4. Never attempt to stop dashboards owned by other Unix users.
   - Cross-user dashboard termination should be treated as out of scope for hermes update.

Suggested implementation direction:
- update _find_stale_dashboard_pids() in hermes_cli/main.py to return only same-UID dashboard PIDs
- keep exclude_pids behavior as-is for the desktop-managed child case
- add regression tests covering:
  - multiple matching dashboard processes owned by different users
  - same-user dashboards are selected
  - other-user dashboards are ignored
  - existing desktop-child exclusion still works

A minimal safe fix would be:
- keep the current command-pattern matching
- add current-UID ownership filtering before returning candidate PIDs

That would preserve the current stale-dashboard cleanup behavior while preventing cross-user interference on shared hosts.