.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
You install Hermes Agent inside WSL2, run hermes gateway start, connect Telegram, all working. You close the terminal. Come back later. Gateway is dead. WSL killed the distro because nothing was running in it.
This is the most-asked Windows-specific Hermes question. WSL2's lifecycle is designed to save memory by shutting down idle distros. Hermes didn't sign up for that. Three patterns keep the gateway running. Pick the one that matches how you use the machine.
Why this happens
WSL2 distros aren't always-on like a real VM. The distro starts when a terminal needs it. It stops when no terminal session is using it, after a short grace period. Microsoft's design choice: save RAM when not in use.
The flip side: anything running inside the distro (Hermes gateway, cron jobs, background services) dies with the distro. systemd inside WSL2 doesn't help with this; systemd manages the gateway right up until WSL pulls the rug from underneath.
Pattern 1: Keep the distro alive with a hidden process
The simplest fix. Run a long-running process inside the distro that WSL counts as "active":
wsl -d Ubuntu-24.04 --exec bash -c "while true; do sleep 3600; done" &That's a Windows command (run in PowerShell) that starts a sleep loop inside Ubuntu without a visible terminal. WSL sees an active process and keeps the distro running. Hermes gateway inside the distro stays alive too.
Make it persistent across reboots via Task Scheduler
- Press Win+R, type
taskschd.msc, Enter - Action menu > Create Task
- General tab: name it "Hermes WSL keepalive"
- Triggers tab: New > Begin the task: At log on
- Actions tab: New > Start a program > Program: wsl > Arguments:
-d Ubuntu-24.04 --exec bash -c "while true; do sleep 3600; done" - Settings tab: uncheck "Stop the task if it runs longer than"
- OK
From next Windows login, the distro stays alive automatically. Gateway stays up with it.
Pattern 2: tmux as the foreground holder
This is what I prefer because the gateway runs visibly and I can attach to it any time to read logs.
sudo apt install tmux
tmux new -s hermes -d "hermes gateway start"Detach is automatic. tmux runs the gateway as a backgrounded session.
Attach later to check on it
tmux attach -t hermesDetach with Ctrl+B then D.
This still needs the distro to stay alive
tmux on its own only prevents your terminal from killing the gateway. It doesn't prevent WSL from shutting down the distro when no terminals exist. Combine pattern 2 with pattern 1 or pattern 3.
Pattern 3: Native Windows service wrapping wsl --exec
The most robust option. Windows becomes responsible for keeping the gateway running, with proper restart policies and logging.
The tool I use is NSSM (Non-Sucking Service Manager). Install via chocolatey or download the binary, then:
nssm install HermesGateway "C:\Windows\System32\wsl.exe" "-d Ubuntu-24.04 --exec /home/youruser/.local/bin/hermes gateway start --foreground"
nssm set HermesGateway AppStdout C:\HermesLogs\stdout.log
nssm set HermesGateway AppStderr C:\HermesLogs\stderr.log
nssm set HermesGateway Start SERVICE_AUTO_START
nssm start HermesGatewayWhat this gives you
Service starts at boot. Restarts if it crashes. Logs to files you can tail in PowerShell. WSL stays alive because Windows is keeping a process active in it. Gateway stays up because NSSM is restarting it on failure.
The --foreground flag tells Hermes not to daemonise. NSSM needs the process it manages to stay foreground or it can't track it properly.
About systemd inside WSL2
Recent WSL2 supports systemd if you opt in. Edit /etc/wsl.conf and add:
[boot]
systemd=trueThen wsl --shutdown from PowerShell and re-open the distro. systemd is now running.
Why systemd alone isn't enough
systemd inside WSL is happy to manage and restart the gateway. But systemd cannot prevent WSL itself from stopping. When WSL goes down, systemd goes with it.
What systemd does add: clean restarts after crashes, proper log management via journalctl, ability to apply hardening flags. Enable it. But pair it with pattern 1 or pattern 3 to keep the outer distro alive.
systemd unit file pattern in our Hermes Agent systemd setup tutorial.
Troubleshooting each pattern
Pattern 1 issues
The keepalive process is invisible and easy to forget about. If you forget you set it up and wonder why the distro never shuts down, that's why. To check:
wsl --list --running
schtasks /query /tn "Hermes WSL keepalive"Pattern 2 issues
If WSL goes down (reboot, manual wsl --shutdown), tmux dies with it. You need pattern 1 or pattern 3 to bring everything back automatically.
Pattern 3 issues
NSSM service runs as a specific Windows user. WSL path references need to resolve for that user. If you set up NSSM under your account and a different Windows user logs in, the service might run in the wrong context. Less common but worth knowing.
The bigger trade-off
WSL2 is the right path for Windows devs who want a Linux CLI. It is not the right path for hosting a 24/7 gateway. Every pattern above is a workaround for WSL doing the thing it's designed to do: shut down idle distros.
If your gateway needs to be reliably up, run the agent on a Linux VPS and use Hermes Desktop or WebUI as your Windows interface. Our Hermes Desktop remote backend on VPS covers the hybrid pattern. VPS doesn't care if your laptop is closed or on a different continent.
If the gateway was working but suddenly disconnected
Three usual causes:
- Windows update changed WSL keepalive behaviour
- WSL update changed it
- Your keepalive process died (Task Scheduler disabled, reboot without auto-start kicking in)
Check:
wsl --status
wsl --list --running
schtasks /query /tn "Hermes WSL keepalive"If the distro isn't running and the keepalive task isn't running, that's the cause. Re-enable and restart WSL.
Move the gateway to a VPS
If you're spending more time keeping the gateway up than using it, the LumaDock Hermes Agent template gives you a Linux VPS with the agent ready to run. Laptop becomes a client, not a host. Unmetered bandwidth and no setup fees. Full setup in our Hermes Agent complete guide.
