Skip to content

Instantly share code, notes, and snippets.

@djfdyuruiry

djfdyuruiry/README.md

Last active October 8, 2024 04:54
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950 to your computer and use it in GitHub Desktop.
Download ZIP
WSL 2 - Enabling systemd
Raw
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
Raw
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
@rrodrigueznt
Copy link

rrodrigueznt commented Jan 4, 2023

@4wk-, all,

A first result: I have two running Ubuntu distros on the same WSL2 installation.

Ubuntu 22.04 is running smoothly and has systemd activated as per below:

rjr@IGFAE-MU-05-DellXPS-Windows10:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
rjr@IGFAE-MU-05-DellXPS-Windows10:~$ systemctl status logrotate.timer
● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Wed 2023-01-04 08:27:58 CET; 3min 34s ago
    Trigger: Thu 2023-01-05 00:00:00 CET; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jan 04 08:27:58 IGFAE-MU-05-DellXPS-Windows10 systemd[1]: Started Daily rotation of log files.
rjr@IGFAE-MU-05-DellXPS-Windows10:~$

Ubuntu 20.04 runs smoothly if I don't activate systemd:

ricardo@IGFAE-MU-05-DellXPS-Windows10:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
ricardo@IGFAE-MU-05-DellXPS-Windows10:~$ cat /etc/wsl.conf
#[boot]
#systemd=true
ricardo@IGFAE-MU-05-DellXPS-Windows10:~$ systemctl
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
ricardo@IGFAE-MU-05-DellXPS-Windows10:~$

But if troughs the aforementioned error The connection information for this resource is invalid when I launched it with systemd=true in ```/etc/wsl.conf````. Thus, I concluded so far that the WSL Genie issue relates with each installed distro, and it is possible to install fresh ones without need to remove the whole WSL2 thing. I will investigate further about the in troubles Ubuntu installation and keep this thread posted! Any comment is always welcome. Thanks.

@redlinejoes
Copy link

redlinejoes commented Jan 4, 2023

I get the impression that you guys intend to keep your WSL systems for some length of time. The whole idea of WSL and containers is that they can be deleted and recreated quickly and easily without fuss. If you intend to keep a Linux system, install a VM. The WSL installation can be easily broken by Windows updates or any random software you install, like Genie. It would be wiser to install a VM and perform a snapshot of the VM before you install system-altering software like Genie. This way, you can always revert.

If you dig deep enough, you can find ways to copy/export your WSL VHD for backup and recovery purposes or to move it to a different location, but it is an Internal Development Platform (IDP). It's not intended to be kept for any length of time on the system after you develop some software.

If your system doesn't work with systemd and Genie, it would be faster and easier just to delete the installation and reinstall WSL Ubuntu from MSStore using the latest version and enable systemd and do not return to this Gist since it has been deprecated now with the latest versions of WSL.

@rrodrigueznt
Copy link

rrodrigueznt commented Jan 4, 2023

@redlinejoes Got it! I will delete and forget my in-troubles Ubuntu 20.04 VHD. I can easily agree with your POV. Thanks!

@4wk-
Copy link

4wk- commented Jan 4, 2023 •
edited
Loading

@redlinejoes I respectfully disagree: in my opinion, WSL is meant to be use for interoperability with Windows, which it does perfectly. Also, in my usage, WSL is a lot better that a VM performance-wise and convenient-wise. I use WSL to run docker containers when I need testing things "on the go", and delete/recreate containers. But my WSL daily use is, indeed, in the long term.

Be that as it may, your initial comment was just at the right moment as it taught me (and others probably) that wsl now support native systemD, which is great, and after cleaning wsl from genie, everything is working perfectly for me! So everything's fine 🙂

@redlinejoes
Copy link

redlinejoes commented Jan 4, 2023

Technically speaking, WSL is a VM. The main difference is the kernel. The kernel in WSL distributions is different because Microsoft develops it. Per Microsoft, it is intended to be used for interoperability during development. Everyone can read the docs here: https://learn.microsoft.com/en-us/windows/wsl/about.

During development on Windows, you absolutely should be using WSL for Docker. There is nothing to disagree with. What you describe are development purposes.

If someone intends to keep a heterogeneous Linux system for production, they should use the Linus-developed kernel distributions in a VM.

There are valid reasons why this is best practice from Microsoft and the Linux community and not a matter of opinion. Using the documentation from Microsoft, I'll go ahead and elaborate so others can know the differences.

From the documentation: https://learn.microsoft.com/en-us/windows/wsl/faq#who-is-wsl-for-
Who is WSL for?
"This is primarily a tool for developers, especially web developers, those working on open source projects, or deploying to Linux server environments. WSL is for anyone who likes using Bash, common Linux tools (sed, awk, etc.) and Linux-first frameworks (Ruby, Python, etc.) but also enjoys using Windows productivity tools."

From the documentation: https://learn.microsoft.com/en-us/windows/wsl/faq#can-i-use-wsl-for-production-scenarios--
Can I use WSL for production scenarios?
"WSL has been designed and built to use with inner loop development workflows. There are design features in WSL that make it great for this purpose but may make it challenging for production-related scenarios compared to other products. Our goal is to make clear how WSL differs from a regular VM environment, so you can make the decision on whether it fits your business needs."

The main differences between WSL and a traditional production environment are:

  • WSL has a lightweight utility VM that starts, stops and manages resources automatically.
  • If you have no open file handles to Windows processes, the WSL VM will automatically be shut down. This means if you are using it as a web server, SSH into it to run your server and then exit, the VM could shut down because it is detecting that users are finished using it and will clean up its resources.
  • WSL users have full access to their Linux instances. The lifetime of the VM, the registered WSL distributions, etc., are all accessible by the user and can be modified by the user.
  • WSL automatically gives file access to Windows files.
  • Windows paths are appended to your path by default, which could cause unexpected behavior for certain Linux applications compared to a traditional Linux environment.
  • WSL can run Windows executables from Linux, which could also lead to a different environment than a traditional Linux VM.
  • The Linux kernel used by WSL is updated automatically.
  • GPU access in WSL happens through a /dev/dxg device, which routes GPU calls out to the Windows GPU. This setup is different than a traditional Linux set up.
  • There are other smaller differences compared to bare metal Linux and more differences are expected to arise in the future as the inner loop development workflow is prioritized.

In summary, Microsoft is saying that WSL is not intended to replace running Linux as a VM, regardless of how WSL performs. WSL can do certain things that make it ideal for development workflows. However, it's been designed to operate differently than users expect from a typical Linux system. This makes it not ideal for production or long-running utilization. The confusion can stem from when a development tool is released to the public, and non-developers start to use it and think it's something it is not.

@4wk-
Copy link

4wk- commented Jan 7, 2023

So I misunderstood you earlier, sorry. I wasn't talking of production use. My use of WSL is only for developing purposes, and I do agree with you! Thanks!

@dominsights
Copy link

dominsights commented Jan 12, 2023

It didn't work for Ubuntu 22. I've used Ubuntu 20 and it worked fine.

This git and the methods described are deprecated.

You should NOT be using this method any longer. The author needs to update this Gist to inform users that this is no longer necessary. WSL has been updated for Windows 10 to match what is available in Windows 11.

You should NOT be using this Gist or the methods described in this repo to enable systemd in WSL for Windows 10 or 11.

To enable the systemd support in Windows 10 or 11, you only need to update your WSL installation.

On Windows 10, when you run the WSL --version command, you should see the following: WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2364

On Windows 11, when you run the WSL --version command, you should see the following: WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.25267.1000

If you run the latest version of WSL, you can enable the systemd support without issue in Ubuntu 22.04. So that you know, you will want to install WSL from the MS Store. Then you can enable the systemd support using the "/etc/wsl.conf" file with the following options: [boot] systemd=true

Follow these instructions for help. The procedure works on Windows 11; as of November 2022, it also works on Windows 10. https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/

It doesn't work on Windows 10. I have tried this multiple times, the only thing that worked was using the Ubuntu 20 and the method the author said above. Please don't remove the gist.

@dominsights
Copy link

dominsights commented Jan 12, 2023

Nevermind, I forked it.

@redlinejoes
Copy link

redlinejoes commented Jan 13, 2023 •
edited
Loading

Please read the documentation for WSL upgrades.

Check your version of WSL on Windows 10 by using the following command:
wsl --version

If that command does not return WSL version: 1.0+, you do not have the correct version of WSL.

You can fork this Gist, but you'll still be using deprecated code and methods that are no longer supported and should not be used.

If you want support for WSL, we can help you.
What is the actual issue you are experiencing?
What exactly does not work on Windows 10?
What did you specifically try that failed?

Post the response to the wsl --version command and also check that you have properly configured systemd using the Microsoft supported and recommend method using "/etc/wsl.config"

@Guidoow
Copy link

Guidoow commented Mar 14, 2023 •
edited
Loading

Works perfectly on Debian!
Thanks!

But there is a little problem when I do systemd

starting with PID 1 "init"
with and without being superuser:
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

starting with PID 1 systemd: (wsl genie -s)

Failed to create /user.slice/user-1000.slice/session-c3.scope/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied

as super user:
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

About xdg_runtime_dir:
env | grep XDG_RUNTIME_DIR

XDG_RUNTIME_DIR=/run/user/1000

Any kind of help would be appreciated, im very new on linux, thanks!

Note that i do not need to execute systemd because systemctl actually works fine, I just want to solve this and know what is wrong. <3

@redlinejoes
Copy link

redlinejoes commented Mar 14, 2023

Works perfectly on Debian! Thanks!

But there is a little problem when I do systemd

starting with PID 1 "init" with and without being superuser: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

starting with PID 1 systemd: (wsl genie -s)

Failed to create /user.slice/user-1000.slice/session-c3.scope/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied

as super user: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

About xdg_runtime_dir: env | grep XDG_RUNTIME_DIR

XDG_RUNTIME_DIR=/run/user/1000

Any kind of help would be appreciated, im very new on linux, thanks!

Note that i do not need to execute systemd because systemctl actually works fine, I just want to solve this and know what is wrong. <3

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.

@tuxflo
Copy link

tuxflo commented Mar 14, 2023 •
edited
Loading

It may be worth mentioning, that the "updated way" of enabling systemd also works in Windows 10 (not just Windows 11 as stated in the header section of the gist).
I was using this method for a long time because I thought the official way is Windows 11 only and my company managed PC is not able to upgrade to Windows 11.
Just update WSL and follow the official docs on how to enable systemd.

@Mart-Bogdan
Copy link

Mart-Bogdan commented Mar 14, 2023 •
edited
Loading

It may be worth mentioning, that the "updated way" of enabling systemd also works in Windows 10 (not just Windows 11 as stated in the header section of the gist).

Yeah. Thanks, @tuxflo. I can confirm that it works on Windows 10.0.19045.2604

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

Option with genie allowed you to chose whether to launch systemd)

@Guidoow
Copy link

Guidoow commented Mar 14, 2023

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?

@tuxflo
Copy link

tuxflo commented Mar 14, 2023

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).

@Mart-Bogdan
Copy link

Mart-Bogdan commented Mar 15, 2023

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 ?

@Mart-Bogdan
Copy link

Mart-Bogdan commented Mar 15, 2023

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
Copy link

Guidoow commented Mar 15, 2023 •
edited
Loading

@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!

@redlinejoes
Copy link

redlinejoes commented Mar 16, 2023

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.

@tertek
Copy link

tertek commented Jun 27, 2023 •
edited
Loading

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

@redlinejoes
Copy link

redlinejoes commented Jul 2, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment