Fix "System has not been booted with systemd as init system" and "Failed to connect to bus"

ps -p 1 -o comm=
# WSL: enable systemd, then run "wsl --shutdown" in Windows PowerShell
printf '[boot]\nsystemd=true\n' | sudo tee -a /etc/wsl.conf

The messages in this family:

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to connect to bus: No such file or directory
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined
Running in chroot, ignoring command 'start'

What the error means

systemctl, journalctl --user, hostnamectl, timedatectl and loginctl do not do the work themselves. They send requests to systemd (PID 1, or the per-user systemd --user manager) over a socket or D-Bus. These errors mean there is nothing to talk to: either systemd is not the init system in this environment, or the user manager for your account is not running or cannot be found.

Two quick checks tell you which case you are in:

ps -p 1 -o comm=
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"

Cause 1: WSL without systemd

Older WSL setups and distributions imported by hand start with Microsoft's own init, not systemd. Current WSL supports systemd, and new Ubuntu installs from the Microsoft Store usually have it enabled already. Enable it yourself:

sudo nano /etc/wsl.conf

[boot]
systemd=true

Then, in Windows PowerShell:

wsl --update
wsl --shutdown

Start the distribution again and check with ps -p 1 -o comm=; it should print systemd. If it does not, check wsl --version on the Windows side: systemd needs a WSL release from the Store, not the old built-in Windows component. If you cannot enable systemd, most services still start with their own command (for example sudo service ssh start where a SysV script exists, or running the daemon binary directly).

Cause 2: Docker, Podman and other containers

A container usually runs exactly one program as PID 1, with no init system. Tutorials that say systemctl start nginx inside a Dockerfile or docker exec fail here by design. Do it the container way:

# run the service in the foreground as the container's main process
CMD ["nginx", "-g", "daemon off;"]

# or start a second process by hand inside a running container (testing only)
docker exec -it web nginx

Put separate services (web server, database, cache) in separate containers and connect them with Docker Compose rather than starting several daemons in one. See Docker on Linux for Compose basics.

If you really need a systemd-managed system, use a tool built for that: Podman can run systemd as PID 1 in a container (it sets up the needed mounts when the command is /sbin/init or systemd), and LXD/Incus or systemd-nspawn run full system containers. On the host, run the container itself as a systemd service if you want it supervised.

Cause 3: a chroot from a live USB

When you repair an installation with chroot (or arch-chroot), you run inside the installed system's files, but PID 1 is the live system's init. systemctl recognises this and refuses commands that need a running manager:

Running in chroot, ignoring command 'start'

Commands that only change files still work, and are all you need during a repair:

systemctl enable ssh
systemctl disable gdm
systemctl mask some-broken.service

Start or test services after you reboot into the repaired system. The GRUB rescue guide shows a full chroot setup.

Cause 4: no user bus after su, sudo or in cron

systemd starts a user manager ([email protected]) and creates /run/user/UID when a user logs in through a real login session: the desktop, a console or SSH. su otheruser, sudo -u otheruser and cron do not create such a session, so systemctl --user has no bus and fails with the "XDG_RUNTIME_DIR not defined" or "No such file or directory" message.

Options, from cleanest to quickest:

# 1. use a proper login
ssh otheruser@localhost
machinectl shell otheruser@        # needs systemd-container package on some distros

# 2. talk to that user's manager directly (it must be running)
sudo systemctl --user -M otheruser@ status myjob.service

# 3. keep the user manager running without a login (servers, background jobs)
sudo loginctl enable-linger otheruser

Lingering is the usual fix for user services that must run at boot, such as rootless Podman containers or a personal sync daemon. For a one-off you can also set the variable by hand: sudo -u otheruser XDG_RUNTIME_DIR=/run/user/$(id -u otheruser) systemctl --user status, but only if that user's manager is already running.

Running sudo systemctl --user is a common mistake too: it talks to root's user manager, not yours. Drop the sudo for user units.

Cause 5: a distribution that does not use systemd

Alpine, Devuan, Void, Gentoo (OpenRC profile), Artix and antiX use other init systems. systemctl is either missing or a stub. Use the native tools:

Distro notes

• Ubuntu, Debian, Fedora, Arch, openSUSE, Mint: all boot with systemd on bare metal and VMs, so on a normal install these errors almost always point to cause 4 (user bus) or to a container/WSL context.
• Ubuntu on WSL: the Store images enable systemd for new installs; distributions imported with wsl --import from a tarball may not have /etc/wsl.conf set.
• Fedora and openSUSE: machinectl is part of the systemd-container package; on Debian and Ubuntu it is also systemd-container; Arch includes it in systemd.

How to prevent it

• Check ps -p 1 -o comm= before following a systemd tutorial inside WSL, a container or a minimal image.
• Design containers around one foreground process, not around systemctl.
• For user services that must survive logout, enable lingering once instead of starting them from cron or su.

Once systemd is reachable, a "Unit not found" message is a different problem; see Unit X.service not found. The systemd basics guide and systemctl cheat sheet cover day-to-day use.

Frequently asked questions