Systemd support is now available in WSL!

Craig Loewen

Systemd support is now available in WSL!

The Windows Subsystem for Linux (WSL) can now run systemd inside of your WSL distros, empowering you to do more with your Linux workflows on your Windows machine.

This post will cover:

  • What is systemd? What can you do with it?
  • How is this change possible in WSL?
  • How can you get systemd on your machine?

For a summary, check out the video below:

What is systemd? What can you do with it?

From :

Systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.

Many popular distributions run systemd by default, such as Ubuntu, Debian and more. This change means that WSL will be even more similar to using your favorite Linux distros on a bare metal machine, and will let you use software that depends on systemd support.

A few examples of Linux applications that depend on systemd are:

  • snap
    • A handy binary that allows you to install and manage software inside Ubuntu.
    • Try running: snap install spotify or snap install postman
  • microk8s
  • systemctl
    • A tool that’s part of systemd, interact with services on your Linux machine
    • Try systemctl list-units --type=service to see which services are available and their status

How is this change possible in WSL?

Supporting systemd required changes to the WSL architecture. As systemd requires PID 1, the WSL init process started within the Linux distribution becomes a child process of the systemd. Because the WSL init process is responsible for providing the infrastructure for communication between the Linux and Windows components, changing this hierarchy required rethinking some of the assumptions made with the WSL init process. Additional modifications had to be made to ensure a clean shutdown (as that shutdown is controlled by systemd now) and to have compatibility with WSLg, It is also important to note that with these change, systemd services will NOT keep your WSL instance alive. Your WSL instance will stay alive in the same way it did before, which you can read more about here.

Given that this changes how WSL behaves when booting up, we wanted to be careful about applying this to user’s already existing WSL distros. So currently you need to opt-in to enable systemd for a specific WSL distro, and we will monitor feedback and investigate making this behavior by default in the future.

How can you get systemd on your machine?

To get started, you will need to do these two things: – Ensure you are running the right version of WSL: Version 0.67.6 and above – Set the systemd flag set in your WSL distro settings

Ensuring you are on the right WSL version

This change is only available in the Microsoft Store version of WSL version 0.67.6 and higher. You can check your version number by running wsl --version. If that command fails then you are running the in-Windows version of WSL and need to upgrade to the Store version.

This version of WSL is now available in the Microsoft Store to users on Windows Insiders build for initial testing, and then after a few weeks we will make it available to all users to ensure quality. You can run wsl --update to check for any WSL updates.

If you are not on Windows Insiders and want to use it immediately, you can download the latest release from the WSL release page.

Set the systemd flag set in your WSL distro settings

You will need to edit the wsl.conf file to ensure systemd starts up on boot.

Add these lines to the /etc/wsl.conf (note you will need to run your editor with sudo privileges, e.g: sudo nano /etc/wsl.conf):


And close out of the nano editor using CTRL+O to save and CTRL+X to exit.

Final steps

With the above steps done, close your WSL distro Windows and run wsl.exe --shutdown from PowerShell to restart your WSL instances. Upon launch you should have systemd running. You can check this with the command systemctl list-unit-files --type=service which should show your services’ status.

Acknowledgements and Feedback!

Thank you to the Canonical team for working with us to deliver this feature! Check out Canonical’s blog post here. For any technical issues please file them on the Microsoft/WSL Github repo. You can follow up with WSL team members, or with me on Twitter. Lastly, learn more about WSL, including how to set up common development tools like Git, VS Code, Docker containers, databases, GPU acceleration for machine learning, and more, by visiting the WSL documentation.

EDIT: We’d also like to personally acknowledge and thank our community members for creating their own systemd implementations on top of WSL. Such as: diddledani’s one-script-wsl2-systemd implementation, cerebrate’s genie, Pengwin’s systemd support and null_po_head_en‘s Distrod! The community passion around systemd in WSL was a factor in deciding to create the Microsoft implementation.


Discussion is closed. Login to edit/delete existing comments.

  • sL1pKn07 SpinFlo 6


    then. is (retro)compatible with Windows 10 WSL2?


    • Carlos Ramirez 0

      No, due to the WSL store version is only available on Windows 11

    • Loongphy Wei 0

      You can try to download release version.

      • Fritz Emboli 0

        This is not much of a win 🙂
        Download is not the problem – it fails to install, because the machine is not “compatible”.

    • Owen Davies 6

      Would love to see this work in Windows 10 + WSL2.

      I’ve been using systemd in WSL for a while via genie/bottle but that feels vulnerable to breakage at any update. I’d much rather be using built-in systemd. However, this is on my work PC and we aren’t likely to move to Windows 11 any time soon. Please keep up the great work and make this work with Windows 10.

      • 哲西 何 0

        Same to me,I want to configure the gnome desktop of my wsl2 and it requires systemd.This link provide a script to achieve this goal but it’s obviously not a compatible solution.So I wish win10 can be supported soon

  • Gian-Luca Sozzi 1

    Craig, you are freaking awesome!

    • 15945252 0

      test reply

  • Duy Bui 0

    You can check this with the command systemctl list-unit-files --type=service which should show your services’ status.

    Actually, that command ran successfully while my wsl version was still 0.66. systemctl start a service still failed.
    After updating to 0.67, both commands succeeded.

  • Nicolas Bihan 0

    Tried to update manually WSL preview but getting an error from admin powershell command

    Add-AppxPackage .\Microsoft.WSL_0.67.6.0_x64_ARM64.msixbundle
    Add-AppxPackage: Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it modifies are currently in use.
    error 0x80073D02: Unable to install because the following apps need to be closed MicrosoftCorporationII.WindowsSubsystemForLinux_0.66.2.0_x64__8wekyb3d8bbwe.
    NOTE: For additional information, look for [ActivityId] 95558484-c91b-0006-9557-67951bc9d801 in the Event Log or use the command line Get-AppPackageLog -ActivityID 95558484-c91b-0006-9557-67951bc9d801

    I was not able to stop the service as it’s restarting automatically even when start is set on demand…

  • Robert Castles 0

    Very impressive. Thanks for sharing!

  • Alexei 0

    If I upgrade the “in-Windows” version of WSL to the Window Store version, will it break my existing Ubuntu installation?

    • Dani Llewellyn 0

      It should not break your existing installations. The upgrade path is designed to be seamless between the inbox WSL that is part of Windows and the preview version of WSL via the Windows Store.

  • Ian MacLean 2

    Very nice. One more step to making WSL a fully functional linux development environment. I’ve applied the config to one of my WSL Ubuntu images and systemd is starting up. However systemctrl commands ( and the snap example you gave ) timeout or error. For example :

    ‘ snap install postman
    error: cannot communicate with server: timeout exceeded while waiting for response’

  • Tamus JRoyce 0

    Will systemd be available for windows 11 wsl1 as well?

    My AzureVM doesn’t support virtualization. And not using gpl licensed linux kernel is a huge plus.

    If this won’t support wsl1, could you update documentation which version of wsl you mean?

    • Dani Llewellyn 1

      I don’t think this is possible in WSL1 without a lot of extra work on the WSL side. Systemd uses features of Linux that WSL1 simply does not implement, such as cgroups (being the main one). Therefore, unless MS invest a lot of effort on the now deprecated WSL1 to implement features of Linux that aren’t already inbox, it is not going to happen. 😞

      • Tamus JRoyce 1 – there is no official word that wsl1 is deprecated as far as I know. But thank you for cgroups being a likely blocker for now.

        If docker and lxc/lxd could take advantage of windows kernel without virtualization, it would be really worth it.

        Even though my use case is blocked, this will help others. I hope they update the documentation appropriately too, if possible.

    • Robin Holt 1

      I don’t understand how “… not using a GPL licensed linux kernel” is a plus at all.

      GPLv2 does not extend beyond the kernel/userland barrier. You are clearly not extending WSL2’s kernel, or you would have looked at its source and seen it is riddled with GPLv2 code taken directly from the Linux kernel. Using WSL2 gives you no license advantage over using any other virtualization platform. You do, however, loose the natural native hardware-like environment they provide.

      • Adam Heathcote 1

        A lot of big corps are scared of open source licenses. Everything must be proprietary and vendor backed. They probably have a need to run WSL for some ass backwards reason and need it to be non-open-source.

  • Carlos Ramirez 2

    Thank you, @Craig, for the recognition of the community efforts. This is really appreciated.

  • Stephen Bovy 0

    thanks for all the great work

    does systemd support, mean we now have a method to create and support ,
    INIT scripts?

    • Dani Llewellyn 0

      Systemd should operate as on a bare-metal linux installation. Specifically for your request, you are now able to write and install arbitrary systemd .service unit description files and .socket unit description files and have those activated automatically during the distro’s startup.

Feedback usabilla icon