Quick fix
# Inside WSL: enable systemd
echo -e "[boot]\nsystemd=true" >> /etc/wsl.conf
# Windows side: restart the distro (required, otherwise no effect)
wsl --terminate <distro-name>
wsl -d <distro-name>
# Verify
ps -p 1 -o comm= # must print systemd
systemctl is-system-running
What you will run into
Inside WSL, systemctl start docker / systemctl status xxx fails with System has not been booted with systemd as init system (PID 1). Can't operate. (or Failed to connect to bus).
Every "service xxx start" tutorial fails in WSL — WSL2's default PID 1 is not systemd, and this is exactly the state you get when [boot] systemd=true is not configured.
Why this happens
WSL2's lightweight VM runs Microsoft's own init as PID 1 by default (not systemd). systemctl needs systemd as PID 1 to operate the service bus; otherwise it reports the error above.
Since September 2022 WSL supports [boot] systemd=true in /etc/wsl.conf to make systemd PID 1.
systemd only works when it is PID 1: it must take over cgroups, mounts, sockets and service state. WSL's default init only does minimal boot and provides no service semantics, so systemctl / journalctl all fail.
The enable path = [boot] section in wsl.conf + restart the distro (wsl --terminate <distro> or wsl --shutdown) — wsl.conf is read only at boot, so editing without restarting is a no-op; this is the second most common cause of this pitfall.
Deterministic takeaway: seeing System has not been booted with systemd means wsl.conf lacks [boot] systemd=true (or it was not restarted); ps -p 1 -o comm= printing systemd is what "actually enabled" looks like.
Step by step
1. Check who PID 1 is — Must do
ps -p 1 -o comm=
systemd = already enabled, the error has another cause; init = not enabled.
2. Write wsl.conf — Must do
echo -e "[boot]\nsystemd=true" >> /etc/wsl.conf
If a [boot] section exists, only add the systemd=true line.
3. Restart the distro — Must do
# Windows side (PowerShell/CMD)
wsl --terminate <distro-name>
wsl -d <distro-name>
4. Verify the service bus is usable — Must do
ps -p 1 -o comm= # systemd
systemctl is-system-running # running / degraded both count as usable
systemctl start docker # the original command now works
How to confirm it works
ps -p 1 -o comm= prints systemd; systemctl is-system-running no longer reports the booted error; systemctl status <service> works for the service you wanted.
Other environments
| Environment | Note |
|---|---|
| systemd not enabled | PID 1 = init; systemctl reports System has not been booted with systemd |
| Enabled | PID 1 = systemd; systemctl / journalctl fully usable |
| Old WSL (< 0.67.6 / before 2022-09) | [boot] systemd=true unsupported; run wsl --update first |
Symptom
$ systemctl status docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Signature: every systemctl subcommand reports the booted error; ps -p 1 is not systemd; wsl.conf lacks [boot] systemd=true or was edited without a restart.
Cause
WSL2's default PID 1 is WSL's own init, not systemd; systemctl requires systemd as PID 1. /etc/wsl.conf [boot] systemd=true enables systemd, and the distro must be restarted for the new init to take over.
Solution
ps -p 1 -o comm=to identify PID 1;- Add
[boot] systemd=trueto wsl.conf; - Restart the distro from Windows with
wsl --terminate <distro-name>; - Verify
ps -p 1 -o comm== systemd, then rerun the original command.
Verification Evidence
- Mechanism check: Microsoft official docs (learn.microsoft.com/windows/wsl/systemd), URL in the evidence log;
- Local comparison (2026-08-31): custom prebuilt WSL — PID 1 = systemd,
systemctl is-system-running= degraded, wsl.conf already has[boot] systemd=true— healthy-path verification; did not reproduce with systemd disabled (to avoid affecting the working environment);
Evidence details kept locally (2026-08-31)
Related canonicals
Read in order: precondition -> same root / same domain / related:
- Related (similar errors, different cause):
- WSL fails to register a distro (WSL distro lifecycle)
- Default user becomes root after import (another wsl.conf pitfall: restart required)
Applicable tools (1)
This problem is linked from the tool pages below — reachable from either side.
wslSource & evidence
← Coding Agents & Terminal domain | Problem Catalog Experience | Facing another issue? Go to the Helpdesk