Are you encountering the frustrating error message “System has not been booted with systemd as init system (PID 1). Can’t operate.”
when trying to manage services with systemctl? This comprehensive troubleshooting guide explains why this error occurs and provides detailed solutions for each common scenario, whether you’re working with Docker containers, WSL environments, or chroot systems.
Understanding Why Systemd Errors Occur in Different Linux Environments
When you see this error message, it indicates you’re attempting to use systemd commands in an environment where systemd isn’t functioning as the init system. This situation commonly arises in:
- Docker containers that don’t have systemd configured as their init process
- Chroot environments which don’t automatically run a separate init system
- Windows Subsystem for Linux version 1 (WSL 1) which doesn’t support systemd
- Specialized Linux distributions that use alternative init systems like SysVinit or Upstart
To understand why this happens, it’s important to know what systemd actually does in a Linux system.
What is Systemd and Why Does it Need to be PID 1?
Systemd serves as the first process started during the Linux boot sequence, receiving the special Process ID 1 (PID 1). As the system’s init process, it has several critical responsibilities:
- Initializing the system by starting and managing all other system processes
- Mounting filesystems
- Managing system services, sockets, and devices
- Handling system state changes (like shutdown and restart)
The systemctl command-line tool requires communication with this systemd process running as PID 1. When it can’t find systemd in that role, you receive the “System has not been booted with systemd” error.
Read: How to Troubleshoot and Optimize Ubuntu Startup: Manage Systemd Services for Faster Boot Time
Detailed Solutions for Different Environments
1. Fixing Systemd Errors in Docker Containers
Docker containers typically don’t run systemd by default. Instead, they run a single application process directly as PID 1, or use a lightweight process manager.
Recommended Approaches for Docker:
Option 1: Avoid Using Systemctl in Containers (Best Practice)
Rather than trying to force systemd into containers, restructure your container workflow to:
# Instead of systemctl start nginx
nginx -g 'daemon off;'
# Instead of systemctl start apache2
apache2ctl -D FOREGROUND
# For custom applications, run them directly
/path/to/your/application
Option 2: Run Systemd Inside Docker (Advanced, Not Generally Recommended)
If you absolutely need systemd inside a container:
FROM ubuntu:22.04 # Install systemd RUN apt-get update && apt-get install -y systemd systemd-sysv # Clean up unnecessary services RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \ rm -f /lib/systemd/system/multi-user.target.wants var wpcf7 = {"apiSettings":{"root":"https:\/\/net2.com\/wp-json\/contact-form-7\/v1","namespace":"contact-form-7\/v1"},"cached":"1"};