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.

  • 浩然 李 0

    So basically this doesn’t work on wsl1? If so, I think the title of this post should be “Systemd support is now available in WSL2!”.

  • Tim Wright 1

    This is excellent news!
    One small problem I ran into with my existing Ubuntu 20.04 install (that I hadn’t updated in quite a while) was that an apt upgrade failed trying to update systemd due to a “cross-device link error”. I tracked this down to /usr/lib/tmpfiles.d/tmp.conf and /usr/lib/tmpfiles.d/x11.conf which are mounted/redirected thus:

    crw-rw-rw- 1 root root 1, 3 Sep 23 07:35 tmp.conf
    -rw-r--r-- 1 root root  568 Aug 31 08:27 var.conf
    crw-rw-rw- 1 root root 1, 3 Sep 23 07:35 x11.conf

    I simply ran sudo umount on each of them and was then able to upgrade successfully.
    Then wsl shutdown restart the instance and all is well.
    I hope that helps anybody else who runs into this.


  • Krzysztof Żelechowski 0

    What is WSLg?

    • Adam Heathcote 0

      The graphical portion of WSL2. You can run Linux GUI apps in Windows using WSLg.

  • 燕鹏 李 2

    plz make this happen on windows 10 + wsl2.

  • Roberto m 0

    ubuntu 22.04 wsl2 not iptables v1.8.4 (legacy): can’t initialize iptables table `filter’: Table does not exist (do you need to insmod?)
    Perhaps iptables or your kernel needs to be upgraded.

    pip install iptables-stats not install

  • Giuliano Cardinali 0

    Hello everybody. Is it only for me that enabling systemd via /etc/wsl.conf breaks applications like xcalc or xeyes?

    I noticed that with systemd enabled, the directory /tmp/.X11-unix/X0 disappeared. Actually, it seems a symlink to /mnt/wslg/.X11-unix.

    With the file /etc/wsl.conf containing


    the folder /tmp/.X11-unix/X0 is present.

    giuliano@PC-GIULIANO10:~$ ls -la /tmp/.X11-unix/
    total 4
    drwxrwxrwx 2 root root 60 Sep 27 21:33 .
    drwxrwxrwt 21 root root 4096 Sep 27 21:33 ..
    srwxrwxrwx 1 giuliano giuliano 0 Sep 27 21:33 X0

    If the systemd variable is set to true, at the next wsl reboot the folder disappears:

    giuliano@PC-GIULIANO10:~$ cat /etc/wsl.conf
    giuliano@PC-GIULIANO10:~$ ls -la /tmp/.X11-unix/
    total 4
    drwxrwxrwt 2 root root 40 Sep 27 22:22 .
    drwxrwxrwt 21 root root 4096 Sep 27 22:22 ..

    Obviously, launching any X app resolves in the following error:

    giuliano@PC-GIULIANO10:~$ xcalc
    Error: Can’t open display: :0

    Any clue or suggestion?

  • David Sanchez 0

    In theory, this would let us keep the SSH Agent service running even after closing the terminal?

    • Brian Richardson 0

      It never needed systemd to do this:

      if [ ! -f ~/.ssh/.agent ]; then
          ssh-agent > ~/.ssh/.agent
      . ~/.ssh/.agent > /dev/null 2>&1
      if [ "`pidof ssh-agent`" != "$SSH_AGENT_PID" ]; then
          unset SSH_AUTH_SOCK
          unset SSH_AGENT_PID
          ssh-agent > ~/.ssh/.agent
          . ~/.ssh/.agent > /dev/null 2>&1
      echo Agent PID $SSH_AGENT_PID
  • Brian Richardson 0

    Thanks very much for delivering this extremely useful feature!

  • Christian Denat 1

    Nice function.

    But it breaks my ubuntu distro (22.04).

    When enable, I need to wait for more than 3 minutes to have the prompt with this error :
    – Failed to get properties: Transport endpoint is not connected

    Checking with ‘ systemctl list-unit-files –type=service’ is really long too – not sure it is ok –

    Here’s my system info :

    PS C:\Users\christian> wsl --version
    Version WSL :
    Version du noyau :
    Version WSLg : 1.0.45
    Version MSRDC : 1.2.3575
    Version direct3D : 1.606.4
    Version de DXCore :

    I’m on W11 PRO dev insider
    Thanks for any help

  • hu Prof 0

    I’m confused which WSL version is available for Win 10 22H2. For example


    has been advertised to be part of previews since 2020, but it doesn’t work on my up-to-date Win 10, 2 years later. Is that still an Insider exclusive functionality? I tried to use the WSL Preview from the Store, that one doesn’t even start.

    • Adam Heathcote 0

      Systemd in WSL2 on Windows 10 is not supported by this method.

Feedback usabilla icon