Run systemd on WSL2 Distro

Tony Tannous
6 min readSep 25, 2022

According to MS official documentation for WSL, systemd support can be enabled for WSL version 0.67.6+.

The WSL blog states that systems running Windows Insiders build can upgrade to the latest WSL version by downloading the update from the Microsoft Store.

If you’re not running Windows Insider, you can still download the latest release from the WSL official git repo releases section.

For example, the following steps describe the procedure for enabling systemd on kali-linux for systems not running Windows Insider edition:

  • Ensure target WSL distro has latest updates applied
PS C:\> wsl -d kali-linux bash -c "sudo apt update && sudo apt upgrade"
  • Check current version of WSL
PS C:\> wsl --version
WSL version:
  • If running version is <0.67.6, download the latest *.msixbundle update for WSL from official git repo releases section
  • Install the .msixbundle
  • After installation is complete, check to ensure WSL has been updated
C:\>wsl --version
WSL version:
  • Add the following to /etc/wsl.conf WSL distro
└─$ cat /etc/wsl.conf
  • shutdown the distro
PS C:\> wsl --terminate kali-linuxThe operation completed successfully.
  • Check systemd is running
PS C:\> wsl -d kali-linux$ ps 1PID TTY      STAT   TIME COMMAND
1 ? Ss 0:00 /lib/systemd/systemd

Procedure Enabling systemd for WSL version <0.67.6


  • Enable systemd on WSL2 Kali Linux distro using the one-script variant of the systemd hack for WSL2, sourced from git repo :
  • Although the steps outlined in this article were tested against Kali, the hack should work with other WSL2 distributions
  • Refer to the documentation within git repo for further details on supported distributions


  • The script was tested on Windows 11 Pro, version 21H2 using Kali Linux, downloaded from Microsoft Store
[~]-> cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"

Preparing WSL2 Distro

To simplify script deployment, passwordless sudo access for the target distribution username will be enabled.

This can always be reverted after systemd has been enabled.

Enable Passwordless sudo for WSL distro

  • To enable passwordless sudo, edit /etc/sudoers
sudo visudo
  • Append the following line, replacing kali with the default username associated with target WSL distro:
#includedir /etc/sudoers.d
  • Save changes with Ctrl+S and exit using Ctrl+X.
  • Apply system updates
[~]-> sudo apt update \
&& sudo apt upgrade -y

Running the systemd Hack Script

  • From a Windows terminal, launch a PowerShell Administrator session
  • Note that Desktop edition of Powershell is used, i.e. PSEdition: Desktop
    ▪ Refer to the documentation on alternatives
  • Once within the session, change to an appropriate directory for saving the required script (to be downloaded in subsequent steps)
  • Run the following to install the wsl PowerShell module
PS C:\apps> Install-Module -Scope CurrentUser Wsl
PS C:\apps> Invoke-WebRequest -Uri '' -OutFile 'install.ps1'
  • Confirm the name of the target WSL distro, where systemd is to be enabled
PS C:\apps> wsl --list
Windows Subsystem for Linux Distributions:
  • Confirm the default username for the target distro
PS C:\apps> wsl -d kali-linux  "whoami"
  • Run the systemd hack script, substituting the values of distro name and default username as obtained from the previous steps
    ▪ For the below example, distro name: kali-linux and default username: kali) are used
    ▪ Also, note that debug option has been enabled to allow for isolation and debugging of each process/command triggered by the installation script
PS C:\apps> powershell.exe -NoProfile -ExecutionPolicy Bypass -File install.ps1 -distro kali-linux -NoGPG -NoKernel -user kali --debug
  • Respond with Y for subsequent prompts
  • If there are no errors, the script should complete with the following message
You may now close this window...
  • Reboot WSL2
PS C:\apps> wsl --terminate kali-linux

Dealing with Errors during Script Execution

  • For any failures encountered, identify the cause and rerun the install script
  • For example, the following shows output of a failed run
DEBUG: --- Enabling custom systemd services in kali-linuxConfirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Y"): Y
ln: failed to create symbolic link '/etc/systemd/system/': No such file or directory
Wsl.exe returned exit code 1 from distro: kali-linux
  • After some troubleshooting, the cause is found to be a result of an attempt to create a symlink at a non-existent path, i.e.
[~]-> ls  /etc/systemd/system/
ls: cannot access '/etc/systemd/system/':
No such file or directory
  • To resolve the issue, logon to the WSL distro, and manually create the path
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\apps> wsl -d kali-linux bash[/mnt/c/apps]-> sudo mkdir -p /etc/systemd/system/[/mnt/c/apps]-> exit
  • Attempt to rerun the installation script once again:
PS C:\apps> powershell.exe -NoProfile -ExecutionPolicy Bypass -File install.ps1 -distro kali-linux -NoGPG -NoKernel -user kali --debug
  • Continue responding Y to prompts, and if all goes well, the script should complete with the following message
You may now close this window...
  • Reboot WSL2
PS C:\apps> wsl --terminate kali-linux

Confirming systemd is Running

  • Logon to the distro and check systemd is running
PS C:\apps> wsl -d kali-linux bashWaiting for systemd to finish booting
Systemd is ready. Logging in.
[~]-> ps 1
1 ? Ss 0:00 /usr/lib/systemd/systemd

Troubleshooting systemd Services

  • Check if any systemd services have failed to launch and examine logs to detemine best approach for resolving
[~]-> sudo systemctl list-units --failed
  • Returns that service systemd-sysusers.service failed to load
UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
systemd-sysusers.service loaded failed failed Create System Users
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.
  • Display the service status by running
[~]-> sudo systemctl status systemd-sysusers.service
  • The following shows the error related to the service
× systemd-sysusers.service - Create System Users
Loaded: loaded (/lib/systemd/system/systemd-sysusers.service; static)
Active: failed (Result: exit-code)
Docs: man:sysusers.d(5)
Process: 30 ExecStart=systemd-sysusers (code=exited, status=243/CREDENTIALS)
Main PID: 30 (code=exited, status=243/CREDENTIALS)
Notice: journal has been rotated since unit was started, output may be incomplete.
  • Quick web search returns the following link, which discusses a workaround:
  • The workaround involves adding a “drop in”/override for the service systemd-sysusers.service
  • To include the override, run edit for the service definition
[~]-> sudo systemctl edit systemd-sysusers.service
  • and add the following

to the override config file, as shown below:

GNU nano 6.4 /etc/systemd/system/systemd-sysusers.service.d/.#override.conf88db274d3ba96c11 *         ### Editing /etc/systemd/system/systemd-sysusers.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file
### Lines below this comment will be discarded### /lib/systemd/system/systemd-sysusers.service
  • Save changes and exit (ctrl+s followed by ctrl+x)
  • The override file should now have been created at /etc/systemd/system/systemd-sysusers.service.d/override.conf with the following contents:
[~]-> cat /etc/systemd/system/systemd-sysusers.service.d/override.conf
  • Restart the systemd-sysusers.service service
[~]-> sudo systemctl restart systemd-sysusers.service
  • Check its status for errors
[~]-> sudo systemctl status systemd-sysusers.service
  • This shows the service is now running successfully
● systemd-sysusers.service - Create System Users
Loaded: loaded (/lib/systemd/system/systemd-sysusers.service; static)
Drop-In: /etc/systemd/system/systemd-sysusers.service.d
Active: active (exited) since Sun 2022-09-25 16:56:04 AEST; 7s ago
Docs: man:sysusers.d(5)
Process: 676 ExecStart=systemd-sysusers (code=exited, status=0/SUCCESS)
Main PID: 676 (code=exited, status=0/SUCCESS)
  • Check for failed units
[~]-> sudo systemctl list-units --failed

returns no failed services

0 loaded units listed.



Tony Tannous

Learner. Interests include Cloud and Devops technologies.