WSL 2 - Enabling systemd

README.md

Enable systemd in WSL 2

NOTE: If you have Windows 11 there is now an official way to do this in WSL 2, use it if possible - see MS post here (WINDOWS 11 ONLY)

This guide will enable systemd to run as normal under WSL 2. This will enable services like microk8s, docker and many more to just work during a WSL session. Note: this was tested on Windows 10 Build 2004, running Ubuntu 20.04 LTS in WSL 2.

• To enable systemd under WSL we require a tool called systemd-genie

• Copy the contents of install-sg.sh to a new file /tmp/install-sg.sh:

  cd /tmp
  wget --content-disposition \
    "https://gist.githubusercontent.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950/raw/952347f805045ba0e6ef7868b18f4a9a8dd2e47a/install-sg.sh"

• Make it executable:

  chmod +x /tmp/install-sg.sh

• Run the new script:

  /tmp/install-sg.sh && rm /tmp/install-sg.sh

• Exit the WSL terminal and shutdown the WSL env:

  wsl --shutdown

• To open a new WSL terminal with systemd enabled, run:

  wsl genie -s

• Prove that it works:

  sudo systemctl status time-sync.target

install-sg.sh

#! /usr/bin/env bash
set -e

# change these if you want
UBUNTU_VERSION="20.04"
GENIE_VERSION="1.44"

GENIE_FILE="systemd-genie_${GENIE_VERSION}_amd64"
GENIE_FILE_PATH="/tmp/${GENIE_FILE}.deb"
GENIE_DIR_PATH="/tmp/${GENIE_FILE}"

function installDebPackage() {
  # install repackaged systemd-genie
  sudo dpkg -i "${GENIE_FILE_PATH}"

  rm -rf "${GENIE_FILE_PATH}"
}

function downloadDebPackage() {
  rm -f "${GENIE_FILE_PATH}"

  pushd /tmp

  wget --content-disposition \
    "https://github.com/arkane-systems/genie/releases/download/v${GENIE_VERSION}/systemd-genie_${GENIE_VERSION}_amd64.deb"

  popd
}

function installDependencies() {
  sudo apt-get update

  wget --content-disposition \
    "https://packages.microsoft.com/config/ubuntu/${UBUNTU_VERSION}/packages-microsoft-prod.deb"

  sudo dpkg -i packages-microsoft-prod.deb
  rm packages-microsoft-prod.deb

  sudo apt-get install apt-transport-https

  sudo apt-get update
  sudo apt-get install -y \
    daemonize \
    dotnet-runtime-5.0 \
    systemd-container

  sudo rm -f /usr/sbin/daemonize
  sudo ln -s /usr/bin/daemonize /usr/sbin/daemonize
}

function main() {
  installDependencies

  downloadDebPackage

  installDebPackage
}

main

The procedure described in this gist has been out of date for over 4 months. Nobody should follow this guide anymore. It's deprecated. It should be removed from the Internet, so it stops people from following it. Too many people come here, fail to read the comments and end up in your situation. At this time, this gist is causing more harm than good. It is especially concerning the amount of "very new to linux" users that stumble on this gist and have a bad experience with WSL or Linux in general.

I don't think so @redlinejoes, maybe you can explain more.
If "no one should use this guide", how can a WSL user use systemctl any other way? In my case, I couldn't use systemctl before (because PID 1 = init != systemd) and now I can with this script.
I just flagged a simple error with the systemd command and|or the configuration. I tried a few commands (including systemctl) that didn't work before, but now with this script, are perfectly working and solved some of my problems.

I found another method to start with systemd as PID 1 which is detailed here:
https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
But it throws similar errors as this method, and some more like "Failed to connect to bus: No such file or directory" when tried to execute systemctl without super user.

There is any method that u recommend to solve this?

But start up time is slower than raw WSL without systemd.

Well I guess you could simulate the switch between systemd and non systemd with a script that toggles the boolean value systemd = true in the wsl.conf but I'm happy with systemd at all time (since I had reasons for enabling it).

I found another method to start with systemd as PID 1 which is detailed here:
https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
But it throws similar errors as this method, and some more like "Failed to connect to bus: No such file or directory" when tried to execute systemctl without super user.

@Guidoow did you run wsl --update ?

Well I guess you could simulate the switch between systemd and non systemd with a script that toggles the boolean value systemd = true in the wsl.conf but I'm happy with systemd at all time (since I had reasons for enabling it).

@tuxflo but you need to run WSL first, yes? Coz that file is inside /etc/wsl.conf, not on a host.

But that's fine, yes. Benefits are better, can wait few seconds :-)

@Guidoow did you run wsl --update ?

@Mart-Bogdan yes, I did.
After WSL and Debian reinstallation and properly update, using this script, It is working PERFECT, Including the above error of systemd $XDG_RUNTIME_DIR. Thanks!

I don't think so @redlinejoes, maybe you can explain more. If "no one should use this guide", how can a WSL user use systemctl any other way?

There is any method that u recommend to solve this?

You are operating with the assumption that the last six months of development didn't happen.

There is no reason for that when all the necessary information is included in this thread.

This leads one to believe you have yet to read and comprehend it.

The answer you seek is explained in detail in this thread. You must do yourself a favor and read my previous comment fully.
https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950?permalink_comment_id=4410998#gistcomment-4410998

There is no reason anyone should use the methods described in this guide. This Gist does more harm than good and is damaging to the open-source software community since the release of WSL version: 1.0.3.0.

This is much easier in 2023, source: https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
Just ensure you have the latest version of WSL:

wsl --update
wsl --version

# soemthing like this
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3086

Simply add within your distro, e.g. Ubuntu inside /etc/wsl.conf:

[boot]
systemd = true

This is much easier in 2023, source: https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/ Just ensure you have the latest version of WSL:

wsl --update
wsl --version

# soemthing like this
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3086

Simply add within your distro, e.g. Ubuntu inside /etc/wsl.conf:

[boot]
systemd = true

It's been this way since 2022.
Read my reply from Dec 2022.
I copied the link here for you to make it easier for you to find and read.

https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950?permalink_comment_id=4410998#gistcomment-4410998