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

systemctl talks to the systemd process that runs as PID 1. When PID 1 is something else, it stops with System has not been booted with systemd as init system (PID 1). Can't operate., usually followed by a line starting with Failed to connect to bus. This happens in WSL distributions without systemd enabled, inside Docker containers and in chroots. In WSL, turn systemd on in /etc/wsl.conf; in a container, run the program in the foreground instead of starting it as a service.

Check what PID 1 is

ps -p 1 -o comm=

systemd means systemctl will work. init (WSL without systemd), bash, sh, node, tini or any application name means it will not.

Fix in WSL 2

Supported since WSL 0.67.6 (wsl --version shows yours; wsl --update updates it). Inside the distribution:

[boot]
systemd=true

Then, from PowerShell or cmd on Windows, restart every WSL instance:

wsl.exe --shutdown

Open the distribution again and check with systemctl status or systemctl list-unit-files --type=service. Recent Ubuntu images installed with wsl --install already have systemd enabled.

Fix in Docker and other containers

A container normally runs one process and has no init system. Start the service's binary in the foreground as the container's command:

# instead of RUN systemctl start nginx / CMD ["systemctl", "start", "nginx"]
CMD ["nginx", "-g", "daemon off;"]

For packages whose install scripts call systemctl enable, the error during docker build is usually harmless: nothing needs to be enabled in an image. Running full systemd in a container is possible (for example with Podman's --systemd=always) but is meant for testing init setups, not for normal application images.

The service command

On Debian and Ubuntu, service NAME start runs the SysV init script in /etc/init.d/ when systemd is not PID 1, so sudo service ssh start works in WSL without systemd, for packages that still ship such a script.