Skip to content
WSLFix Published Updated 3 min readViews unavailable

Fixing systemd User Services That Stop When a WSL Session Closes

A WSL systemd lifecycle guide covering user managers, linger, targets, journal evidence, environment, distro termination, Windows startup, and honest limits.

A systemd user service normally belongs to the user’s service manager, whose lifecycle follows logind sessions unless lingering is enabled. In WSL, there is a second boundary: the entire distribution/WSL VM can be terminated by wsl --terminate, wsl --shutdown, updates, reboot, or WSL’s own lifetime policy. loginctl enable-linger addresses the user-manager boundary; it does not turn WSL into an always-on Windows service platform.

Confirm systemd and unit ownership

Inside the distribution:

ps -p 1 -o comm=
systemctl --user status example.service
systemctl --user is-enabled example.service
loginctl user-status "$USER"
journalctl --user -u example.service -b

PID 1 should be systemd if WSL systemd support is enabled. If it is not, verify the current Store WSL version and /etc/wsl.conf [boot] systemd=true, then save work and restart the distro with wsl --shutdown from Windows. Installing systemd packages alone does not activate WSL’s supported boot integration.

Ensure the unit is actually a user unit under ~/.config/systemd/user or a system user-unit directory. A system unit uses sudo systemctl, not systemctl --user, and has different identity/environment. Do not move a privileged daemon into a user unit merely to avoid administrative configuration.

Enable at the right user target

A conventional long-running user unit includes:

[Unit]
Description=Example background worker
After=network-online.target

[Service]
ExecStart=%h/bin/example-worker
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=default.target

Use an absolute executable and explicit environment; user managers do not necessarily inherit an interactive shell’s PATH, version-manager setup, or agent sockets. network-online.target does not guarantee a remote Internet service is reachable, so the worker still needs timeouts/backoff.

Reload and enable:

systemctl --user daemon-reload
systemctl --user enable --now example.service
systemctl --user status example.service

If it stops exactly at logout/session close, inspect logind state and enable lingering for the intended ordinary user with administrative authorization:

sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" -p Linger

Lingering starts/retains the user’s manager independently of an interactive login within the running Linux system. It also means user services can consume resources when the user is absent. Audit enabled units and disable linger when no longer needed.

Distinguish logout from distro termination

Close the terminal and, from Windows, check wsl --list --running. Reopen and inspect journalctl --user -b plus systemctl --user show timestamps. If the boot ID changed, the distro restarted; lingering did not fail. If the same boot remained but the user manager stopped, inspect logind/unit configuration.

Microsoft’s systemd announcement explicitly notes that systemd services do not keep a WSL instance alive contrary to WSL’s established lifecycle. Do not promise a database, monitoring agent, or server will run continuously just because its unit is enabled. For Windows-boot startup, an organization may use a properly secured Scheduled Task that starts the distro/unit after prerequisites, but that adds Windows credentials, triggers, failure monitoring, and shutdown behavior to own.

Workloads requiring guaranteed 24/7 availability, inbound service SLA, or reboot orchestration belong in a Windows service, VM, container host, or Linux server designed for that role.

Verify all boundaries

Test terminal close, wsl --terminate <Distro>, wsl --shutdown, Windows sign-out/reboot, sleep, WSL update, network loss, service crash, and user disablement. Confirm journal persistence/forwarding if logs must survive distro removal. A correct fix states which boundary it solves: linger preserves the user manager inside a running distro; external orchestration or a different platform handles Windows/WSL lifetime guarantees.

Related:

Sources:

Comments