I am attempting to debug some C# / .NET 5 code in WSL 2 with Ubuntu on Windows. I have WSL 2 setup with Windows 10 and want to test out creating a Systemd service. Unfortunately, it appears Systemd is not enabled with WSL 2 by default, even though a standard Ubuntu install does have it enabled by default. Is there any way to get Systemd enabled in WSL 2?
Note: See footnote at bottom of this answer for background on this Community Wiki.
There are several possible paths to enabling Systemd on WSL2 (but not WSL1). These are summarized here, with more detail provided below.
Option 1: Upgrade WSL to the latest application release (if supported by your system) and opt-in to the Systemd feature
Option 2: Run a Systemd-helper script designed for WSL2
Option 3: Manually run Systemd in its own namespace
And while not part of this question, for those simply looking to run certain applications that require Systemd, there are alternatives:
On WSL1 and WSL2:
Alternative 1: SysVInit scripts (e.g. sudo service <service_name> start) where available
Alternative 2: Manually configuring and running the service
On WSL2-only:
Alternative 3: Docker
Should you enable Systemd in WSL?
First, consider whether you should or need to enable Systemd in WSL. Enabling Systemd will automatically start a number of background services and tasks that you really may not need under WSL. As a result, it will also increase WSL startup times, although the impact will be dependent on your system. Check the Alternatives section below to see if there may be a better option that fits your needs. For example, the service command may do what you need without any additional effort.
More detail on each answer:
Option 1: Upgrade WSL to the latest application release (if supported by your system) and opt-in to the Systemd feature
Microsoft has now integrated Systemd support in the WSL2 application release (as opposed to the older "Windows feature" implementation).
Starting with WSL Application Release 1.0.0, this feature is available on both Windows 10 and Windows 11. Windows 10 users do need to be on UBR (update build revision) 2311 or later. The UBR is the last 4 digits of your full Windows build number (e.g. 10.0.19045.2311 for Windows 10 22H2). 2311 is installed with KB5020030, an optional Preview update, although if you are reading this later, it will likely be a later (non-Preview) monthly servicing update.
If you are on a supported Windows release, the WSL application with Systemd support can be installed:
Through the Microsoft Store (as "Windows Subsystem for Linux").
Or from the Releases page in the Github repo. To install a release manually:
Reboot (to make sure that WSL is not in use at all). A simple wsl --shutdown may work, but often will not.
Download the 1.0.0 (or later) release from the link above.
Start an Administrator PowerShell and:
Add-AppxPackage <path.to>/Microsoft.WSL_1.0.0.0_x64_ARM64.msixbundle
wsl --version # to confirm
To enable, start your Ubuntu (or other Systemd) distribution under WSL (typically just wsl ~ will work).
sudo -e /etc/wsl.conf
Add the following:
[boot]
systemd=true
Exit Ubuntu and again:
wsl --shutdown
Then restart Ubuntu.
sudo systemctl status
... should show your Systemd services.
Option 2: Run a Systemd-helper script designed for WSL2
There are a number of Systemd-enablement scripts available from various sources. Given the complexities involved in running Systemd under WSL, it is recommended that you:
Use one that is actively maintained
Attempt to understand, as much as possible, how they operate, and how they may impact other features and applications in your distribution(s) under WSL
When asking questions here or on any other site, disclose in the question which script you are using so that others can attempt to understand and/or reproduce your issue in the proper context
Several of the more popular projects that enable Systemd under WSL2 are:
Genie: 1.8k stars, last commit September, 2022
Distrod: 1.4k stars, last commit July 2022
WSL2-Hacks: 1.1k stars, mostly instructional, with a supporting script example. Last commit January, 2022
At the core, all of them operate on the same principles covered in the next option ...
Option 3: Manually run Systemd in its own namespace
One of the main issues with running Systemd in earlier versions of WSL is that both inits need to be PID 1. To get around this, it is possible to create a new namespace or container where Systemd can run as PID 1.
To see how this is done (at a very basic level):
Run:
sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=basic.target
This starts Systemd in a new namespace with its own PID mapping. Inside that namespace, Systemd will be PID1 (as it must, to function) and own all other processes. However, the "real" PID mapping still exists outside that namespace.
Note that this is a "bare minimum" command-line for starting Systemd. It will not have support for, at least:
Windows Interop (the ability to run Windows .exe)
The Windows PATH (which isn't necessary without Windows Interop anyway)
WSLg
The scripts and projects listed above do extra work to get these things working as well.
Wait a few seconds for Systemd to start up, then:
sudo -E nsenter --all -t $(pgrep -xo systemd) runuser -P -l $USER -c "exec $SHELL"
This enters the namespace, and you can now use ps -efH to see that systemd is running as PID 1 in that namespace.
At this point, you should be able to run systemctl.
And after proving to yourself that it's possible, it is recommended that you exit all WSL instances completely, then doing wsl --shutdown. Otherwise, some things will be "broken" until you do. They can likely be "fixed", but that's beyond the scope this answer. If you are interested, please refer to the projects listed above to see how they handle these situations.
Alternative 1: SysVInit scripts (e.g. sudo service <service_name> start) where available
In Ubuntu, Debian, and some other distributions on WSL, many of the common system services still have the "old" init.d scripts available to be used in place of systemctl with Systemd units. You can see these by using ls /etc/init.d/.
So, for example, you can start ssh with sudo service ssh start, and it will run the /etc/init.d/ssh script with the start argument.
Even some non-default packages such as MySql/MariaDB will install both the Systemd unit files and the old init.d scripts, so you can still use the service command for them as well.
On the hand, some packages, like Elasticsearch, only install Systemd units. And some distributions only provide Systemd units for most (if not all) packages in their repositories.
Alternative 2: Manually configuring and running the service
For those services that don't have a init-script equivalent, it can be possible to run them "manually".
For simplicity, let's assume that the ssh init.d script wasn't available.
In this case, the "answer" is to figure out what the Systemd unit files are doing and attempt to replicate that manually. This can vary widely in complexity. But I'd start with looking at the Systemd unit file that you are trying to run:
less /lib/systemd/system/ssh.service
# Trimmed
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
Some of the less relevant lines have been trimmed to make it easier to parse, but you can man systemd.exec, man systemd.service, and others to see what most of the options do.
In this case, when you sudo systemctl start ssh, it:
Reads environment variables (the $SSHD_OPTS) from /etc/default/ssh
Tests the config, exits if there is a failure
Makes sure the RuntimeDirectory exists with the specified permissions. This translates to /run/sshd (from man systemd.exec). This also removes the runtime directory when you stop the service.
Runs /usr/sbin/sshd with options
So, if you don't have any environment-based config, you could just set up a script to:
Make sure the runtime directory exists. Note that, since it is in /run, which is a tmpfs mount, it will be deleted after every restart of the WSL instance.
Set the permissions to 0755
Start /usr/sbin/sshd as root
... And you would have done the same thing manually without Systemd.
Again, this is probably the simplest example. You might have much more to work through for more complex tasks.
Alternative 3: Docker
Many packages/services are available as Docker images. Docker typically runs very well under Ubuntu on WSL2 (specifically WSL2; it will not run on WSL1). If there's not a SysVinit "service" script for the service you are trying to start, there may very well be a Docker image available that runs in a containerized environment.
Example: Elasticsearch, as in this question.
Bonus #1: Doesn't interfere with other packages already installed (no dependency issues).
Bonus #2: The Docker images themselves pretty much never use Systemd, so you can often inspect the Dockerfile to see how the service is started without Systemd. For more information see the next option - "The manual way."
Microsoft recommends Docker Desktop for Windows for running Docker containers under WSL2.
Footnote This answer is being posted as a Community Wiki because it can apply to multiple Stack Overflow questions. It is originally based on answers to this Ask Ubuntu question. However, it is hoped that this wiki-answer can be continuously updated by the community as Systemd evolves on WSL.
This question has been chosen since:
It appears to be the most canonical, straightforward, "How do I enable Systemd on WSL?" question.
It is on-topic, as *creating Systemd services is (or at least can-be) unique to programming.
After exporting .Ova file, containing .ovf and .vhd resources, I'am facing errors during
boot of the VM in VirtualBox/VmwarePlayer. Output ad follow
'''
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.18-419.el5xen ro root=/dev/VolGroup00/LogVo100 console=xvc0
Error 13: Invalid or unsupported executable format
'''
I found the problem. It is related to the custom Xen kernel.
A fix can be found by installing a new kernel, disabling console on /etc/inittab and enabling tty.
Current kernel installed packages
<code># rpm -qa | grep ‘kernel’'</code>
Download the latest RPM
In my case I had to find it because the CentOs is very old
Checking the RPM signature
<code>#rpm -K *rpm</code>
Install/Update non-kernel RPMs (optional in my case)
<code> rpm -Uvh mkinitrd.rpm SysVinit.rpm initscripts.rpm </code>
(optional, for kernel developers)
<code>#rpm -Uvh kernel-headers.rpm kernel-source.rpm</code>
Install Kernel
<code>#rpm -ivh kernel-2.6.18-420.el5.x86_64.rpm</code>
*Note: Use ivh option "install" because Uvh option "Update" will delete previous installed kernel, which may need in case of any unsuccessful update.
Creating Initial RAM disk (optional, only if system has SCSI controllers/SCSI hard drive)
<code>#ls -l /boot/initrd-* </code>
If you can find an image for the currently running kernel, you need to proceed with this command for creating new initrd image for the new kernel:
<code>#mkinitrd /boot/initrd-2.2.17-14.img 2.2.17-14</code>
Verify the grub configuration "/etc/grub.conf"
Grub will be automatically configured with the new kernel upon RPM installation
Anyway if multiple kernels are avaible, you could specify on boot which one you want to use.
In grub.conf, the value “0” to “default” indicates that it will boot from the first kernel mentioned.
Edit /etc/inittab , This file defines three important items for the init process:
The system's default run level
What processes to start, monitor, and restart if they terminate
What actions to be taken when the system enters a new run level
Initializes console and identifies the terminal type
We are going to comment console line and uncomment text-only terminals as follows
##comment this##co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
Reboot the Macchine
In my case, after this operations I've been able to export and start the Vm on VirtualBox avoiding the previous error mentioned.
Till solaris 10, below were the steps I followed to create an inetd service which worked fine for me, below are steps:
Open /etc/inet/inetd.conf file and add my application binary with all required arguments as line below:
myApp_5000 stream tcp nowait root /home/jack/myApp/bin/myApp myApp -h -P /home/jack/myApp/bin
Open /etc/inet/services file and add a entry there also as below:
myApp_5000 5000/tcp
Finally I used to execute the below command:
inetconv -f
This will automatically create my service and everythings works fine till Solaris 10.
But now in Solaris 11, when I perform the same exact steps first I get below error message when I execute command "inetconv -f":
The manifest being imported is from a standard location and should be imported with the command : svcadm restart svc:/system/manifest-import
Secondly, my service gets created but does not works, as it remains in maintenance state always, see below:
svcs | grep myApp
maintenance 12:35:03 svc:/network/myApp_5000/tcp:default
I tried disabling and enabling the service but didn't helped.
Is there anything changed in Solaris 11 with respect to this, or am I doing it in the wrong way.
OS info:
uname -a
SunOS myhost 5.11 11.3 i86pc i386 i86pc
Do an:
ls -ltr /var/svc/log/|tail
look inside the relevant log file for your service, and see if there are any clues...
I have setup a Linux server to run veins/omnet++ simulations on it. The main reason I am doing this is to decrease simulation time. The server is running Ubuntu Server 14.04.3, OMNET++ 4.6, SUMO 0.22.0 and VEINS 4a2. After installing OMNET and SUMO, I changed to VEINS root directory and run ./configure and make MODE=release -j 32. This generated an executable veins-4a2 file that I tried to run as:
./veins-4a2 -u Cmdenv -f examples/veins/omnetpp.ini //since omnetpp.ini is under examples folder
But I got the following error:
Loading NED files from /home/simulator/veins-4a2/examples/veins: 1
<!> Error: NED type `RSUExampleScenario' could not be fully resolved, due to a missing base type or interface.
Before running the previous command I did another ssh into machine to run the command ./sumo-launchd.py -vv -c sumo.
My questions is what does the error refer to? And have I missed any steps during my installation/configuration? Am I doing the make step for veins properly?
For future reference: Specifying the NED Path, or have a look at NED source folder from project properties
I am currently working on centos running on intel atom board. I mistakenly renamed lic-2.17.so to _libc-2.17.so
library on my board, when I reboot the board it is giving me below error.
[ OK ] Reached target Initrd Default Target.
systemd-journald[136]: Received SIGTERM
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
Is there any possible way to get back to the original state.
I entered into grub prompt and able to see cat /lib64/_libc-2.17.so. Not Sure,
how to rename this to original name
Thanks in advance.
Can you enter run-level 3 from grub?
if so,
sudo mv /lib64/_libc-2.17.so /lib64/libc-2.17.so
if you can't enter run-level 3, you can try using a live DVD/USB to run the above command, you're just going to have to manually search for the right partition which the incorrectly named file is located.
Otherwise, I'm afraid you're going to need to reinstall the OS.