System Not Booted With systemd as Init? Fix the Error

Updated 8 November 2026 · Standard formula, shown below

The message “System not booted with systemd as init” means the current environment was started with a different process in charge of system startup, or the command is running somewhere systemd is not PID 1. It often appears when a tool such as systemctl is used inside a container, chroot, or Windows Subsystem for Linux (WSL); the right fix depends on which environment you intended to manage.

What the message means

On a Linux system that uses systemd, the system manager normally starts as process ID 1. It initializes services and other system components, and systemctl communicates with that manager to inspect or control units. The error indicates that the command cannot find systemd acting as the init system for its current environment.

This does not necessarily mean Linux failed to boot. A Linux installation can use another init system, or a restricted environment can omit a system manager entirely. The command may also be pointed at the wrong system: for example, a shell inside a container does not automatically control the host’s services.

Check which environment you are using

Before changing configuration, identify where the command is running and what process is PID 1. These checks are read-only:

Run ps -p 1 -o pid=,comm=,args=. If the output names something other than systemd, systemd is not PID 1 in that environment.
Run cat /proc/1/comm for a quick check of PID 1’s command name.
Check whether you are in a container or WSL. In WSL, uname -a commonly includes “Microsoft”; container environments may expose clues through /proc/1/cgroup, though details vary.
If you used chroot, remember that entering another filesystem does not boot it or start its init system.

These commands help distinguish an ordinary Linux boot from an isolated shell. Do not assume a missing systemd process is a fault until you know which environment is supposed to provide it.

Choose the fix for the environment

On a normal Linux installation: If the computer is supposed to boot with systemd, check PID 1 from a regular local or remote shell, not from a container or chroot. If PID 1 is not systemd, the machine may use a different init system, or boot configuration may have selected another one. Consult the distribution’s documentation before changing the boot setup.

In WSL: systemd support depends on the WSL setup and distribution configuration. On supported installations, it can be enabled by setting systemd=true in the WSL configuration file, commonly /etc/wsl.conf, under a [boot] section. For example:

[boot]
systemd=true

Save the file, then fully stop and restart the WSL instance so the setting is applied. From Windows, wsl --shutdown stops running WSL distributions; starting the distribution again performs a fresh launch. If the configuration option is not supported by the installed WSL version, update WSL through the supported Windows mechanism or use the distribution’s documented alternative. Do not add this setting to a regular Linux system expecting it to change its init system.

In a container: Most containers run one main application rather than a complete operating system with systemd managing services. Use the container runtime or orchestration configuration to manage the container, and run the application in the way its image expects. If you genuinely need systemd inside a container, that requires an image and runtime setup designed for it; simply installing systemd or running systemctl is not enough.

In a chroot: A chroot changes the visible root directory for a process; it does not start a separate kernel or boot a new system. Use the host’s service manager to control host services. For maintenance operations within the chroot, use the target distribution’s documented tools rather than expecting its systemd manager to be running there.

Use the right tool for the task

If systemd is not managing the environment, systemctl is generally the wrong interface. Find out which init system or supervisor is actually present, then use its documented service-management commands. On a system without a service manager, a process may be launched directly by a shell, container runtime, or another supervisor.

For instance, systemctl status example.service asks the systemd manager for a unit’s status. It cannot reliably inspect a similarly named process started independently, and running it with sudo does not create a systemd manager. Likewise, enabling a service with systemctl enable is not the same as starting an application in a container.

Common causes and troubleshooting

Using systemctl in a container: Manage the container through its runtime, or use the application’s intended foreground command. Avoid treating the container shell as the host’s administrative shell.
Running a command in a chroot: Leave the chroot to manage host services. A chroot does not have its own boot sequence.
Using WSL without systemd enabled: Confirm that the installed WSL environment supports systemd, check the configuration spelling and section, then restart the distribution fully.
Using a distribution with another init system: Identify the system’s init and follow its documentation. Installing systemd solely to silence the message may conflict with the system’s design.
Running inside a restricted session: A remote shell, build environment, or service sandbox may not expose the host manager. Use the host’s appropriate management channel.

If this began after a configuration change, undo only the relevant change or consult the distribution’s recovery guidance. Avoid replacing PID 1, deleting system files, or launching a second init process as a quick workaround; those actions can disrupt the system without solving the underlying mismatch.

Frequently Asked Questions

Does this error mean my Linux system is broken?
No. It usually means systemd is not PID 1 in the current environment. That can be normal in WSL, containers, chroots, and systems that use another init system.

Will running systemctl with sudo fix it?
Usually not. Elevated permissions cannot make systemd the init process if another program is PID 1 or no system manager is running.

How can I tell whether systemd is PID 1?
Run ps -p 1 -o pid=,comm=,args=. If the command name or arguments identify systemd, it is likely the init process in that environment.

Can I use systemctl inside Docker or another container?
Not by default. Many containers do not run systemd, so manage their processes through the container runtime or the image’s intended application command. Running systemd inside a container needs deliberate support from both the image and runtime.

How do I enable systemd in WSL?
On a supported WSL installation, configure systemd=true under [boot] in /etc/wsl.conf, then fully stop and relaunch the distribution. Check current WSL documentation if the setting is unavailable.

Is systemd the only Linux init system?
No. Linux distributions can use other init systems or service supervisors. The appropriate commands and service configuration depend on what the distribution actually runs.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.