hermes - 💡(How to fix) Fix Feature request: Auto-start dashboard with gateway systemd service [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#16702Fetched 2026-04-28 06:51:27
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Timeline (top)
labeled ×3commented ×1

In WSL environments with multiple boot cycles (e.g., after Windows updates, hibernation, or manual WSL restarts), the dashboard process dies and does not come back up. The gateway survives via systemd, but the dashboard does not.

Root Cause

In WSL environments with multiple boot cycles (e.g., after Windows updates, hibernation, or manual WSL restarts), the dashboard process dies and does not come back up. The gateway survives via systemd, but the dashboard does not.

Code Example

[Unit]
Description=Hermes Agent Dashboard
After=hermes-gateway.service
Wants=hermes-gateway.service

[Service]
Type=simple
User=<hermes_user>
Group=<hermes_user>
ExecStart=<venv_path>/python3 <hermes_path>/hermes dashboard --host 0.0.0.0 --no-open --insecure
WorkingDirectory=<hermes_agent_dir>
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
RAW_BUFFERClick to expand / collapse

Problem

The Hermes dashboard is not auto-started with the gateway - it runs as a separate process. After WSL restarts or gateway crashes, the dashboard becomes unavailable until manually restarted.

Context

In WSL environments with multiple boot cycles (e.g., after Windows updates, hibernation, or manual WSL restarts), the dashboard process dies and does not come back up. The gateway survives via systemd, but the dashboard does not.

Proposed Solution

Create a separate systemd service for the dashboard that starts after the gateway:

[Unit]
Description=Hermes Agent Dashboard
After=hermes-gateway.service
Wants=hermes-gateway.service

[Service]
Type=simple
User=<hermes_user>
Group=<hermes_user>
ExecStart=<venv_path>/python3 <hermes_path>/hermes dashboard --host 0.0.0.0 --no-open --insecure
WorkingDirectory=<hermes_agent_dir>
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Benefits

  • Dashboard survives WSL restarts and gateway crashes
  • Persistent access to http://127.0.0.1:9119/sessions without manual intervention
  • Consistent behavior with gateway autostart behavior

Note

The --insecure flag is required when binding to 0.0.0.0. In trusted home networks this is acceptable. Alternatively, the dashboard could bind to localhost only if mirrored networking is available

extent analysis

TL;DR

Create a separate systemd service for the Hermes dashboard to ensure it auto-starts after the gateway and survives WSL restarts or gateway crashes.

Guidance

  • Define a systemd service file for the Hermes dashboard with the proposed configuration to establish a dependency on the gateway service.
  • Ensure the ExecStart command includes the correct path to the Python executable and the Hermes dashboard script.
  • Set the Restart option to on-failure to automatically restart the dashboard service if it crashes.
  • Reload the systemd daemon and enable the new service to start automatically after a reboot.

Example

The provided systemd service configuration can be used as a starting point:

[Unit]
Description=Hermes Agent Dashboard
After=hermes-gateway.service
Wants=hermes-gateway.service

[Service]
Type=simple
User=<hermes_user>
Group=<hermes_user>
ExecStart=<venv_path>/python3 <hermes_path>/hermes dashboard --host 0.0.0.0 --no-open --insecure
WorkingDirectory=<hermes_agent_dir>
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Replace <hermes_user>, <venv_path>, <hermes_path>, and <hermes_agent_dir> with the actual values for your environment.

Notes

The --insecure flag is used when binding to 0.0.0.0, which may not be suitable for all environments. Consider binding to localhost if possible.

Recommendation

Apply the proposed workaround by creating a separate systemd service for the Hermes dashboard, as it provides a reliable solution for ensuring the dashboard survives WSL restarts and gateway crashes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Feature request: Auto-start dashboard with gateway systemd service [1 comments, 2 participants]