When attempting to manage services using the systemctl command within a Linux distribution running on the Windows Subsystem for Linux (WSL), particularly WSL2, encountering errors like:

• System has not been booted with systemd as init system (PID 1). Can't operate.
• Failed to connect to bus: Host is down

is a common scenario. These messages typically indicate the same underlying issue related to the init system used by the WSL environment.

This situation arises when trying to perform actions such as starting, stopping, or checking the status of services (e.g., ssh, nginx, docker). This article explores why this happens and outlines several approaches to address the problem, including enabling official support and employing effective workarounds.

Understanding the Root Cause

The core reason for these errors is that traditional WSL environments did not utilize systemd as their primary process manager or init system (the process with PID 1). Most modern Linux distributions, including Ubuntu, rely heavily on systemd for service management, initialization, and various system tasks. The systemctl command is the primary interface for interacting with systemd.

When systemctl is invoked in a WSL instance lacking systemd as PID 1, it cannot connect to the expected systemd control bus, resulting in the observed errors. However, developments in WSL have introduced official support for systemd under specific conditions.

A key distinction exists between older “in-box” versions of WSL (distributed as a Windows feature) and newer versions available as a Windows application via the Microsoft Store or direct download. Native systemd support is primarily available in the application version of WSL.

Read: How to display your sound card details on the terminal on Ubuntu 22.04

Solutions and Workarounds

Depending on the WSL version and system configuration, several methods can resolve or circumvent this issue.

1. Enabling Native Systemd Support (Recommended)

Official support for systemd is available in the application-based version of WSL (version 1.0.0 and later). Enabling it provides the most seamless experience for tools expecting systemd.

Prerequisites:

• WSL Application Version: You must be using the WSL version installed from the Microsoft Store or GitHub, not the older “in-box” Windows feature. You can check if you have the application version by running wsl --version in PowerShell or Command Prompt. If it returns version information, you have the application version. An error indicates the in-box version.
• Windows Version:
  • Windows 11 22H2 or later (automatically uses the application version via wsl --install).
  • Windows 11 21H2 requires manual installation/update of the WSL application.
  • Windows 10 requires update KB5020030 or later (validated on 22H2, potentially works on others).

Steps to Enable Systemd:

1. Install or Update WSL: If you don’t have the required application version, obtain it:
   • From the Microsoft Store (search for “Windows Subsystem for Linux”).
   • From the WSL GitHub Releases page. Download the .msixbundle file (e.g., Microsoft.WSL_1.0.0.0_x64_ARM64.msixbundle or later) and install it from an Administrator PowerShell prompt after rebooting (or at least ensuring WSL is fully shut down with wsl --shutdown):

     Add-AppxPackage #\Microsoft.WSL*.msixbundle

   • Alternatively, try updating via PowerShell:

     wsl --update

     If installing from a source other than the app store, you might need:

     wsl --update --web-download

   Verify the installation with wsl --version.

2. Configure WSL: Start your target Linux distribution (e.g., Ubuntu). Edit the /etc/wsl.conf file with root privileges. Use an editor like nano or vim:

   sudo nano /etc/wsl.conf

   Add the following lines to the file. If the file or the [boot] section already exists, add the systemd=true line under it:

   [boot]
   systemd=true

   Save the file and exit the editor (e.g., in nano, press CTRL+O, Enter, then CTRL+X).

3. Restart WSL: Close all WSL distribution windows. Open PowerShell or Command Prompt and force a full shutdown of WSL:

   wsl --shutdown

4. Verify: Restart your Linux distribution. You should now be able to use systemctl. Check the status:

   sudo systemctl status

   Or list active services:

   systemctl list-unit-files --type=service

Consideration: Enabling systemd might slightly increase WSL startup time and resource consumption due to the background services it manages. If minimal impact is desired, consider the alternatives below.

Read: How to fix Bluetooth connection problems on Ubuntu 22.04

2. Alternatives When Native Systemd is Unavailable or Undesired

If enabling native systemd is not possible or preferred, these alternatives can often manage services effectively.

Option A: Using the ‘service’ Command

Many packages in distributions like Ubuntu include legacy SysVinit (‘init.d’) scripts alongside systemd unit files for compatibility. The service command acts as a wrapper that can utilize these scripts.

Check for available scripts in /etc/init.d/:

ls /etc/init.d/

If a script exists for your service (e.g., ssh, nginx, docker, mariadb), you can typically manage it using:

sudo service # start
sudo service # stop
sudo service # restart
sudo service # status

For example:

sudo service nginx start
sudo service docker start

This works because the service command bypasses systemctl and interacts directly with the older init scripts if found.

Autostarting Services: To automatically start services on WSL launch without using systemctl enable, you can modify /etc/wsl.conf:

[boot]
command="service ssh start; service nginx start"

Remember to run wsl --shutdown after changing wsl.conf.

Option B: Leveraging Docker Containers

For many server applications, running them within Docker containers is a viable alternative. Docker generally performs well under WSL2.

• Containerized applications usually manage their own processes internally, often without relying on the host system’s init system (systemd).
• This isolates dependencies and avoids conflicts with host system configurations.
• Examining a service’s ‘Dockerfile’ can sometimes reveal how it’s started without ‘systemd’.

Note that the Docker daemon itself needs to be started. If native `systemd` isn’t enabled, use the `service` command approach: sudo service docker start (if the init script is provided by the Docker installation).

Option C: Manual Service Execution

This involves understanding what the systemd unit file for a service does and replicating those steps manually.

1. Inspect the service file (e.g., /lib/systemd/system/ssh.service or /etc/systemd/system/...).
2. Identify key directives like ExecStart (the command to run), EnvironmentFile (environment variables), and RuntimeDirectory (required directories, often under /run).
3. Manually execute the necessary setup (e.g., creating directories like /run/sshd, setting permissions) and then run the main executable specified in ExecStart, potentially using sudo.

This approach can be complex and varies significantly between services. It’s generally reserved for cases where other methods fail.

Option D: Using Namespace/Container Scripts (Advanced)

Several third-party projects (e.g., Genie, Distrod, others) provide scripts that enable ‘systemd’ to run within a separate PID namespace inside WSL2. In this namespace, `systemd` can function as PID 1.

Example (Conceptual – Use dedicated scripts for stability):

# Start systemd in a new namespace (basic example)
sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=basic.target

# Wait a few seconds, then enter the namespace
sudo -E nsenter --all -t $(pgrep -xo systemd) runuser -P -l $USER -c "exec $SHELL"

Inside this new shell, systemctl commands should function.

Warnings:

• This is an advanced technique. Using these scripts can fundamentally alter WSL behavior (e.g., Windows interop, path handling, temporary files).
• Potential conflicts or unexpected issues can arise, sometimes affecting other WSL distributions.
• It’s crucial to understand how these scripts work or, at minimum, be aware you are using one when troubleshooting issues.
• Exiting and performing wsl --shutdown is often necessary to reset the environment after experimenting.

Using established, well-maintained projects is strongly recommended over raw ‘unshare’/’nsenter’ commands for practical use.

Considerations for Specific Software

Some software is deeply integrated with systemd, making workarounds difficult:

• Snap: Canonical’s Snap packaging system heavily relies on systemd. Running snaps typically requires native systemd support in WSL.
• Gnome Desktop Environment: While ports exist for non-systemd systems, running the standard Gnome environment on Ubuntu within WSL generally assumes systemd is present.
• Management Tools like Cockpit: Some tools act as front-ends to systemd itself. While they might partially function without it, core features relying on systemctl operations will fail.

Conclusion

The “System has not been booted with systemd” error in WSL stems from the historical absence of systemd as the default init system. With recent updates, enabling native systemd support in the application version of WSL is now the most direct and often preferred solution, especially for software heavily reliant on it.

Where native support is not feasible or desired, alternatives like the versatile service command, containerization with Docker, or manual execution provide effective pathways to manage services within the WSL environment. Advanced namespace techniques exist but require careful consideration due to their complexity and potential side effects.