This list started out on the genie wiki as a collection of the systemd units prone to fail (and thus result in systemd as a whole being listed as “degraded”) when run under WSL. It turns out that these issues also occur when running under the new native systemd support for WSL, so I’m reprinting the list here for general interest.
Here are the well-known-to-be-problematic units:
apparmor.service
While this should not be a problem with recent versions of AppArmor that include my WSL support patch, some distributions include pre-patch versions of AppArmor which, even if you have installed an AppArmor-supporting custom kernel, cause this service to run but exit with the message
Not starting AppArmor in container.
This is working as intended since WSL technically is a container, but leaves the system insecure. To make these versions of AppArmor operate normally under WSL 2, a manual patch is required.
See this article for the details.
auditd.service
auditd.service fails under WSL with the following error(s):
Error - audit support not in kernel
Cannot open netlink audit socket
The default WSL kernel does not include auditing support. (If you have a use case for auditing under WSL, you would need to compile and use a custom kernel which includes it.)
Even if this is done, auditd does not support running within a PID namespace, which WSL intrinsically is. auditd cannot be made to work under WSL at this time. Disable or mask this unit.
cloud-init.service
Some distribution images (including, at the time of writing, the Ubuntu distro) include cloud-init, a tool used to initialize various settings for containers or virtual machines running on cloud providers. This serves no purpose under WSL, and indeed will fail after a lengthy DHCP timeout.
Disable it with the following command:
touch /etc/cloud/cloud-init.disabled
multipathd.service
multipath.service, used to support multiple physical connections to single storage devices, fails under WSL with the following error:
Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
The default WSL kernel does not include the multipath support. If you have a specific use case for multipath under WSL, compile and use a custom kernel which includes it. Otherwise, disable or mask this unit.
ssh.service
ssh.service may fail to start with the following error:
ssh.service: Failed with result 'exit-code'.
and when running /usr/sbin/sshd you get the error:
sshd: no hostkeys available -- exiting.
This is simply the result of sshd not having a configured host key. You can generate a host key by running:
sudo ssh-keygen -A
at which point ssh.service will activate and function normally.
systemd-modules-load.service
The default WSL kernel does not require any kernel modules, and any modules supplied by a distribution are unlikely to match the WSL-supplied kernel.
Unless you are running a custom kernel with module support compiled in/in use, or have otherwise supplied suitable module support, disable or mask this unit.
systemd-networkd.service
NOTE: This does not apply when using bridged networking with WSL, in which case you will need to configure systemd-networkd appropriately for your network.
systemd-networkd.service may fail under WSL (and will often take out your network with it) because it defaults to attempting to manage the physical network interface. Under WSL, this interface is configured before your distribution starts up, and does not use DHCP to do so, leading to errors.
To correct this, mark the eth0 (or other physical interface; check its name using ip a) interface as unmanaged, such that systemd-networkd will not attempt to modify the configuration. This can be done thus, as root:
cat << EOF > /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Link]
Unmanaged=yes
[Network]
DHCP=no
[DHCP]
UseDNS=false
EOF
systemd-networkd-wait-online.service
If this service is listed among the failed units when systemd starts up, this indicates an issue with your network failing to configure itself properly.
This is a consequence of a configuration error with another unit, most likely cloud-init.service or systemd-networkd.service. Check the logs and see the entries for those here.
systemd-remount-fs.service
systemd-remount-fs.service may fail under WSL with the following error:
mount: /: can't find LABEL=cloudimg-rootfs.
This occurs because systemd-remount-fs is trying to remount the root partition to make sure that it has the options configured in /etc/fstab; and the default /etc/fstab assumes that the root partition is labeled "cloudimg-rootfs". This isn't the case under WSL (the root partition is one of its .vhdx files), so the remount fails. (This isn't strictly a problem with the service - you'd get the same error if you tried to remount / manually.)
There are two ways to solve this one: either find the device the root partition is mounted from (probably /dev/sdb, but check first), and label it appropriately:
sudo e2label /dev/sdb cloudimg-rootfs
systemd-sysusers.service
In some distributions, the systemd-sysusers.service (which is responsible for ensuring that users and groups required by the system always exist in the passwd/groups files) fails when started under WSL. If this affects your distribution, a known problem is that the following lines exist in the configuration for this unit, found in the /usr/lib/systemd/system/systemd-sysusers.service file:
# Optionally, pick up a root password and shell for the root user from a
# credential passed to the service manager. This is useful for importing this
# data from nspawn's --set-credential= switch.
LoadCredential=passwd.hashed-password.root
LoadCredential=passwd.plaintext-password.root
LoadCredential=passwd.shell.root
This functionality requires the kernel modules sg and crypto_user, which do not exist and cannot be loaded in the stock WSL kernel. To work around this without using a custom kernel, edit the local override file for the unit with systemctl edit systemd-sysusers.service and add the lines:
[Service]
LoadCredential=
Thanks to @xuanruiqi for tracking this one down (in #190).
The solution for this one has changed. Please see this post.
systemd-timesyncd.service
systemd-timesyncd.service is used to synchronize the local system clock with a remote NTP server. While useful under Linux, the WSL system clock is automatically synced with the host machine.
systemd-timesyncd.service should be skipped under most circumstances (look for the line
Network Time Synchronization was skipped because of a failed condition check (ConditionVirtualization=!container).
in the output of systemctl status systemd-timesyncd). If for some reason it isn’t, mask this unit.
Problematic Systemd Units Under WSL
After switching from `systemd-genie` to `bottle-imp`, I get this failed unit:
```
# systemctl status snapd.seeded.service
× snapd.seeded.service - Wait until snapd is fully seeded
Loaded: loaded (/lib/systemd/system/snapd.seeded.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-10-22 17:49:06 PDT; 2min 48s ago
Process: 617 ExecStart=/usr/bin/snap wait system seed.loaded (code=exited, status=1/FAILURE)
Main PID: 617 (code=exited, status=1/FAILURE)
Oct 22 17:49:06 hostname systemd[1]: Starting Wait until snapd is fully seeded...
Oct 22 17:49:06 hostname snap[617]: Interacting with snapd is not yet supported on Windows Subsystem for Linux.
Oct 22 17:49:06 hostname snap[617]: This command has been left available for documentation purposes only.
Oct 22 17:49:06 hostname systemd[1]: snapd.seeded.service: Main process exited, code=exited, status=1/FAILURE
Oct 22 17:49:06 hostname systemd[1]: snapd.seeded.service: Failed with result 'exit-code'.
Oct 22 17:49:06 hostname systemd[1]: Failed to start Wait until snapd is fully seeded.
```
Maybe should be added? I'd also love to know if there are any workarounds cause my quick searching hasn't found anything.