Microsoft and Canonical Bring systemd Support to WSL

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.

The announcement as a release event

Microsoft announced the integration on September 21, 2022 after engineering work with Canonical. It first required a recent Store-delivered WSL build and an explicit setting in /etc/wsl.conf; it was not an automatic behavior change for every installed distribution on announcement day. That staged rollout mattered because changing PID 1 changes startup, shutdown, service supervision, logging, and assumptions made by distro packages.

Canonical demonstrated the feature with Ubuntu, while Microsoft documented that other distributions could participate when they shipped a sufficiently recent systemd package. The announcement specifically named workloads such as snap, microk8s, and systemctl-managed services that had previously required workarounds. It did not promise that WSL had become a permanently running server or that every physical-hardware service would make sense inside the WSL utility VM.

What changed in adoption terms

The release removed a compatibility objection that had followed WSL since its first version. Linux installation instructions increasingly assumed systemd, and package post-install scripts often expected its tools and unit model. Native support let distributions use that mainstream path instead of maintaining WSL-specific substitutes. Microsoft later made systemd the default for the current Ubuntu installed through wsl --install, while retaining configuration controls for existing environments.

This news post records the announcement, rollout prerequisites, and ecosystem response. The companion deep dive explains the process tree, configuration, lifecycle, and diagnostic consequences.

Primary references: Microsoft’s original announcement, Microsoft Learn: use systemd to manage Linux services with WSL.

Versioning was part of the news

At launch, Microsoft required WSL 0.67.6 or newer and directed users to check with wsl --version. That detail prevents the announcement from being misread as a Windows build guarantee: Store WSL could deliver the integration independently of a large Windows feature update. Documentation and defaults evolved afterward, so a historical reproduction should pin the WSL package, distribution image, and systemd version instead of testing only on a current machine.

Related:

Sources: