Microsoft and Canonical Bring systemd Support to WSL
For years, software expecting systemd to be running as PID 1 simply didn't work correctly inside WSL. That changed in September 2022, closing one of WSL's longest-standing compatibility gaps.
In September 2022, Microsoft and Canonical jointly announced that systemd support was available in WSL2, closing a compatibility gap that had persisted since WSL2’s original 2019 release.
What changed, concretely
The relevant WSL2 build (version 0.67.6 and higher) modified how the WSL2 environment boots, correctly initializing systemd as an actual PID 1 process rather than launching directly into a shell or specified command without any traditional Linux init system running at all.
Why this had remained unsupported for so long
WSL2’s lightweight VM was originally optimized for fast startup, and systemd’s assumptions about controlling cgroups and mount namespaces during boot didn’t align cleanly with that original launch sequence — properly supporting it required real engineering work on WSL2’s boot process itself, not a simple configuration change.
What this fixed for real-world software
Software packaged assuming a systemd-managed distro — certain Docker configurations, various services expecting systemctl to actually work — had either failed outright or required non-standard manual workarounds under WSL2 without this support. With it available, systemctl start/stop/enable commands function as they would on a conventional systemd-based Linux installation.
How to actually get it, and why it’s opt-in
Systemd support ships as an opt-in setting via /etc/wsl.conf, requiring a distro restart to take effect — deliberately not forced on by default for existing distro configurations that hadn’t been built assuming systemd’s presence.
Why this rounded out WSL2’s maturity as a genuine Linux environment
Combined with GPU compute and GUI application support added in the prior two years, systemd support meant WSL2 by late 2022 supported essentially the full range of software behavior a mainstream Linux distro’s users would expect, closing what had been one of the more consistently cited compatibility gaps in comparisons between WSL2 and genuine bare-metal or conventionally-virtualized Linux.
Sources: