systemctl fails in WSL? Check PID 1 and systemd

You run systemctl in WSL to inspect a service and receive an error about PID 1 or a failed bus connection. The command may already be installed, which makes it unclear whether the next step is a package change or a WSL setting.

A useful starting point is the process running as PID 1 inside that Linux environment. Being able to print a systemctl version does not establish that systemd is managing services. Check the WSL requirements, the init process, and then the individual service.

Check the WSL version and execution mode

Run these commands in Windows PowerShell.

wsl --version
wsl --list --verbose

WSL’s systemd support requires WSL version 0.67.6 or later and a distribution running in WSL 2 mode. The VERSION column in the distribution list shows 1 or 2 for the execution mode. It is separate from a WSL product version such as 3.x.

Microsoft describes systemd as enabled by default in the current standard Ubuntu installation. Older environments, other distributions, and manually imported filesystems may have different starting points. Check the Linux state before adding settings to an environment that already has systemd enabled.

Inspect PID 1 inside Linux

Open the Linux terminal for the distribution you want to investigate and run:

ps -p 1 -o comm=
systemctl --version

The first line prints the name of process 1; the second prints the systemctl version. A PID 1 name of systemd identifies a systemd-based boot. A version number alone is insufficient: when another process is PID 1, systemctl may be unable to contact the system service manager.

For example, querying a service in an environment that has not booted with systemd can produce:

System has not been booted with systemd as init system (PID 1). Can't operate.

With this error, investigate the boot method before the application’s service settings. If systemctl cannot be found at all, start with package availability instead. Microsoft’s Debian and Ubuntu guidance calls for systemd-sysv as well as systemd. A missing command and an installed command without a running manager lead to different checks.

Change wsl.conf when needed

If the WSL 2 requirements are met and systemd is not enabled, open that distribution’s /etc/wsl.conf using an editor with the necessary administrative privileges. Keep a separate copy of its existing contents, preserve other settings, and adjust the following entry within the [boot] section.

[boot]
systemd=true

If a [boot] section already exists, edit its systemd setting instead of adding a duplicate section. This Linux file is separate from the .wslconfig file in your Windows user folder. The change concerns the selected Linux environment.

Terminating the distribution stops its terminals, development servers, and other running work. Save your work and finish the relevant processes first. Then use its registration name in Windows PowerShell. Replace Ubuntu below with the exact name shown in your distribution list.

wsl --terminate Ubuntu

Open that distribution again and recheck PID 1. If it has not changed to systemd, revisit the registration name, configuration file location, and entry. To revert a configuration change, restore the saved settings, finish the affected work, terminate and reopen the distribution, and inspect PID 1 again.

Compare service definitions with runtime state

Once systemd is running, you can list installed service definitions:

systemctl list-unit-files --type=service --no-pager

States such as enabled and disabled describe enablement, mainly relating to activation at boot. They are separate from the current active state. This list can also be displayed in some environments where systemd is not PID 1, so a successful listing alone does not confirm that systemd is running.

Use status to inspect a specific unit. This example queries systemd-journald.service, which handles the journal. For an application, use its actual service name.

systemctl status systemd-journald.service --no-pager

Loaded helps identify whether the definition was found, while Active describes runtime state. A not-found result points toward the name or installation; a failed state calls for investigating that service’s error. Enabling a unit does not, by itself, start it immediately. Start and enable serve different purposes. Reading the failure first is more useful than reinstalling a service or restarting unrelated ones.

Plan uptime separately from service management

Systemd support lets you manage compatible applications as Linux services. Microsoft also notes that systemd services do not, by themselves, keep a WSL instance alive. It is therefore not a promise that a server will remain available after WSL terminates or Windows restarts. Consider the application’s uptime requirements separately.

If the service is running but a Windows browser cannot reach it, the next useful check is localhost and the listening port. Before changing an environment you rely on, a WSL backup restored under another name can help you prepare a recovery route.

References

• Microsoft Learn: systemd in WSL
• Microsoft Learn: WSL configuration
• Microsoft Learn: WSL basic commands
• systemd: systemctl
• procps-ng: ps