If your shell reports systemctl: command not found, it cannot find the systemctl executable. That is different from System has not been booted with systemd as init system: in the second case, systemctl was found and ran, but the expected system manager is unavailable.

Identify the environment before installing packages. A full Ubuntu machine, a minimal container, a WSL distribution and macOS can all show you a terminal while using different service-management arrangements.

Run these checks in the shell where the command failed

command -v systemctl
printf '%s\n' "$PATH"
cat /etc/os-release
ps -p 1 -o comm=

The first command checks command lookup. The release file identifies a Linux distribution when present. The final command shows the name of process 1, the initial process in the current process namespace. Seeing systemd supports using systemd tools there; seeing an application or shell is common in containers.

If ps is also absent in a minimal Linux environment, cat /proc/1/comm can provide the process name when procfs is available. Neither check proves that a container can access the host's service manager.

Choose the branch matching your result

ResultNext step
No path for systemctlCheck PATH and your distribution's package/service-manager documentation.
A path is found, but the systemd-not-booted message appearsInspect PID 1 and whether you are in a container, chroot or WSL environment.
The manager responds but a unit is not foundCheck the service's package and unit name. Installing systemctl again will not create that application's unit.
The manager reports degradedIt is running with one or more failed units; inspect the failures rather than treating the executable as missing.

On a normal Ubuntu or Debian installation

Use the package database to inspect the installed systemd package:

dpkg-query -W -f='${Status}\n' systemd

If the package is installed but your shell cannot locate its command, compare PATH with the executable location supplied by that package. The Bash command-not-found guide explains command lookup and temporary PATH tests.

If the package is missing, establish whether that is intentional. Minimal images and distributions using a different init system may deliberately omit it. Follow your distribution's supported repair or installation procedure; adding a command-line utility alone does not replace the process that started the machine.

On a systemd host, these read-only checks help separate manager and unit problems:

systemctl is-system-running
systemctl --failed --no-pager
systemctl list-unit-files --type=service --no-pager

The first command can return a nonzero status for a state such as degraded. Read its output instead of interpreting every nonzero result as a missing command. For Ubuntu SSH, inspect ssh.service and, when present, ssh.socket; see the SSH setup and verification steps.

Inside a container

A container commonly runs its application as PID 1. In our Ubuntu 24.04 test container, systemctl was installed, ps -p 1 -o comm= showed bash, and systemctl status returned the systemd-not-booted error. Installing the command and running a service manager are separate things.

Start and manage a containerized application through its image's documented entrypoint and your container platform. Do not mount host service-manager sockets or use privileged mode just to make a generic systemctl tutorial work.

Inside WSL

First launch the intended WSL distribution. Microsoft documents systemd support for WSL 2, with WSL version 0.67.6 or newer. Check the installed WSL version in PowerShell with wsl --version and the distribution version with wsl --list --verbose.

If your WSL 2 distribution is not already using systemd, Microsoft's documented configuration adds the following section to /etc/wsl.conf. Merge it into the existing file rather than overwriting unrelated settings:

[boot]
systemd=true

Save work in all running WSL distributions before running wsl --shutdown in PowerShell: that command stops all of them. Reopen the distribution and repeat the PID 1 and systemctl checks. Consult Microsoft's instructions for any distribution-specific package prerequisites.

If you are in Git Bash, PowerShell or macOS

Those shells are not automatically sessions inside a systemd Linux host. Open the intended Linux environment or connect to the Linux machine first. If your goal was to run a Bash script rather than manage a service, follow the script execution guide instead.

Sources and verification

Tested September 11, 2026 in Ubuntu 24.04 Docker: a restricted PATH reproduced command-not-found; with the executable available, a container whose PID 1 was Bash reproduced the separate systemd-not-booted error. A normal Ubuntu host was used for read-only environment inspection. WSL configuration changes and systemd boot were not performed in the container.

Other tools that depend on the system manager

The same environment distinction matters when changing a hostname with hostnamectl or diagnosing DNS with resolvectl. A container may use different hostname and resolver controls.