How to Enable systemd in WSL2

systemd support arrived in WSL2 in September 2022 as an opt-in feature — this walks through actually enabling and verifying it.

Step 1: check your current WSL version supports it

wsl --version

Confirm you’re on a sufficiently recent WSL version — if the version looks old, update first.

Step 2: update WSL if needed

wsl --update

Step 3: edit the distro-specific configuration file

sudo nano /etc/wsl.conf

Add or edit the following section:

[boot]
systemd=true

This setting is per-distro, configured from inside the specific distro you want systemd enabled for — it doesn’t affect other installed distros.

Step 4: fully restart the distro for the change to take effect

wsl --shutdown

Then relaunch the distro normally. A simple exit and reopening the terminal is not sufficient — the full shutdown command is required since this changes how the distro’s own init process boots.

Step 5: verify systemd is actually running as PID 1

ps -p 1

This should show systemd as the process running with PID 1 — if it shows something else (like /init or a shell), the setting either wasn’t applied correctly or the required restart didn’t happen.

Step 6: verify systemctl actually works

systemctl status
systemctl list-units --type=service

A working systemd setup shows genuine service status output here, rather than the “System has not been booted with systemd” error that appears without systemd support enabled.

Step 7: test starting and stopping an actual service

sudo systemctl start nginx
sudo systemctl status nginx
sudo systemctl stop nginx

Confirming a real service starts, reports correct status, and stops cleanly verifies systemd is genuinely functional, not just present.

Step 8: enable a service to start automatically with the distro

sudo systemctl enable nginx

With systemd properly running, standard service auto-start configuration behaves exactly as it would on a conventional systemd-based Linux installation.

Step 8b: check systemd’s own view of overall boot health

systemctl is-system-running
systemctl --failed

is-system-running reporting degraded rather than running means at least one unit failed during boot even though the shell and most services still work — worth investigating the specific named failed unit rather than dismissing it, since it might be something you actually depend on despite the rest of the system appearing healthy.

Step 9: troubleshoot if systemd doesn’t appear to be running after the restart

Double-check the /etc/wsl.conf edit was saved correctly, confirm wsl --shutdown was actually run (not just closing the terminal window), and confirm you’re editing the config file inside the correct distro if you have multiple installed.

Why this specific opt-in step, rather than automatic enablement, exists

Enabling systemd changes a distro’s fundamental boot behavior — making it an explicit, per-distro opt-in avoids silently changing how existing distro configurations boot, protecting setups that were specifically configured to work without systemd from an unexpected, disruptive change to their startup behavior. Newer versions of Ubuntu installed fresh through wsl --install do enable systemd by default, so this manual walkthrough matters most for existing distros or non-Ubuntu images that predate or don’t ship with that default.

Remembering this is a permanent boundary event, not a one-time uptime guarantee

Enabling systemd gives you real dependency-ordered service management inside the distribution, but it doesn’t change the fact that the surrounding WSL2 environment itself can still stop — at user logoff, on wsl --shutdown, after certain updates, or following WSL’s own idle-resource policy. Any service you enable this way should be built to handle a clean SIGTERM and restart gracefully, with its actual data durability handled independently of the process’s own uptime, rather than assuming systemd management alone makes a service permanently available.

Confirming a specific service survives a full restart cycle

Beyond the immediate systemctl start/stop test, the more meaningful verification is confirming an enabled service actually comes back up correctly after a full wsl --shutdown and relaunch — some configuration issues (a unit with an incorrect dependency, a service expecting a resource not yet available at boot) only surface on a genuine cold boot, not when simply restarting the service manually while the distribution is already running.

Enabling systemd on additional distros independently

Because [boot] systemd=true lives in each distro’s own /etc/wsl.conf, enabling it on one distro has no effect on any other installed distro — repeat the same edit-and-restart process independently for each distro you want systemd enabled on, and expect distros without the setting to continue booting with WSL’s original lightweight init as before.

Check ps -p 1 first on any distro before assuming this walkthrough is even necessary — you may already be starting from systemd enabled by default.

Reverting cleanly if systemd causes an unexpected problem

Disabling systemd after enabling it is the same edit in reverse — set systemd=false (or remove the line entirely) in /etc/wsl.conf, then wsl --shutdown and relaunch. This returns the distribution to WSL’s original lightweight init, which is a genuinely useful fallback to know about if a specific systemd unit or service turns out to behave unexpectedly in a way that’s easier to walk back than to debug immediately.

Related:

Sources: