Why WSL Didn't Support systemd at First, and How It Works Now
For years, WSL distros ran without systemd — meaning services expecting it simply failed. Here's why that gap existed, and what changed architecturally to finally close it.
For years after WSL2’s release, running systemctl inside a WSL distro produced an error rather than managing services — a gap that broke any software expecting systemd to be running as PID 1, until specific WSL platform changes closed it.
Why systemd wasn’t there from the start
WSL distros originally launched directly into a shell or specified command, without running a traditional Linux init system as PID 1 at all — systemd itself makes assumptions about controlling cgroups, mount namespaces, and the boot sequence in ways that conflicted with how WSL2’s lightweight VM launched its Linux environment, which was optimized for fast startup rather than replicating a full traditional Linux boot sequence.
What broke, specifically, without systemd
Any software depending on systemctl to start, stop, or check the status of a background service — Docker’s daemon on some configurations, various database services, and other software packaged assuming a systemd-based distro — either failed outright or required manual, non-standard workarounds to start services without systemd’s involvement at all.
What Microsoft and Canonical actually changed
Starting with updates in September 2022, Microsoft (working with Canonical) modified WSL2’s launch sequence to properly initialize systemd as an actual PID 1 process inside the Linux environment, correctly integrated with WSL2’s specific cgroup and namespace setup — a genuine architectural change to how the WSL2 environment boots, not just a compatibility shim layered on top.
How to actually enable it
/etc/wsl.conf
[boot]
systemd=trueSystemd support is opt-in per distro via this configuration file, requiring a full distro restart (wsl --shutdown followed by relaunching) to take effect — it’s not automatically enabled for existing distro installations upgrading to a newer WSL version.
Why opt-in, rather than enabled by default
Enabling systemd changes the distro’s boot behavior in ways that could affect distros specifically configured to work without it — making it an explicit, deliberate choice avoids silently changing behavior for existing setups that never expected or needed systemd running.
What actually works once it’s enabled
With systemd running as PID 1, standard systemctl start/stop/enable commands work as they would on a bare-metal or conventionally-virtualized Linux system — meaningfully improving compatibility with software distributed assuming a standard systemd-managed distro, including Docker’s own systemd-based service management in some configurations.
Why this gap mattered enough to justify the architectural work
systemd has become close to universal across mainstream Linux distros over the past decade — software packaged with the reasonable assumption that systemd is available and running increasingly just didn’t work correctly under WSL without it, making this a meaningful compatibility gap rather than a minor missing feature, and explaining why closing it took genuine collaborative engineering between Microsoft and Canonical rather than a simple configuration flag.