How to Fix “System Has Not Been Booted with Systemd as Init System” Error in Linux

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/*; \
    rm -f /etc/systemd/system/*.wants/*; \
    rm -f /lib/systemd/system/local-fs.target.wants/*; \
    rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
    rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
    rm -f /lib/systemd/system/basic.target.wants/*; \
    rm -f /lib/systemd/system/anaconda.target.wants/*;

# Install your service
RUN apt-get install -y nginx

# Enable your service
RUN systemctl enable nginx

VOLUME [ "/sys/fs/cgroup" ]
CMD ["/sbin/init"]

Run this container with:

docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro -d my-systemd-image

Option 3: Use Docker Compose with Systemd Configuration

version: "3.9"
services:
  my_service:
    build: .
    privileged: true
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    cap_add:
      - SYS_ADMIN
    command: /sbin/init

Important Security Note: Running containers with --privileged grants extensive permissions and reduces container isolation. This approach should only be used when absolutely necessary and with careful security considerations.

Read: How to Manage Ubuntu Boot Services: List, Start, and Stop Systemd Services at Startup 

2. Resolving Systemd Issues in Chroot Environments

Chroot (change root) environments create isolated filesystem trees that don’t include a separate init system.

Solutions for Chroot Environments:

Option 1: Manage Services Without Systemctl

Inside a chroot, start and manage services directly:

# Instead of systemctl start mysql
/etc/init.d/mysql start

# Or use the service command if available
service mysql start

Option 2: Access Host Systemd from Chroot (Limited Functionality)

You can bind-mount key directories to interact with the host’s systemd:

# Before entering chroot, mount these directories
sudo mount --bind /run /path/to/chroot/run
sudo mount --bind /sys /path/to/chroot/sys 
sudo mount --bind /proc /path/to/chroot/proc
sudo mount --bind /dev /path/to/chroot/dev

# Then enter the chroot
sudo chroot /path/to/chroot

This approach allows you to query host services but not reliably manage services within the chroot itself.

3. Enabling Systemd in Windows Subsystem for Linux (WSL)

WSL has different approaches depending on which version you’re using.

For WSL 1 Users (No Systemd Support):

WSL 1 doesn’t support systemd at all. Your options are:

Option 1: Upgrade to WSL 2 (Strongly Recommended)

# In PowerShell (Admin)
wsl --set-version Ubuntu-22.04 2

Option 2: Use Alternative Service Management in WSL 1

If you must remain on WSL 1, use direct service management:

# Start services directly
sudo /etc/init.d/ssh start
sudo service mysql start

# For databases like MySQL
sudo mysqld_safe &

# For web servers
sudo apache2ctl start

For WSL 2 Users (Systemd Support Available):

Enable Systemd in WSL 2 (Ubuntu 22.04 and newer)

# Edit the WSL configuration file
sudo nano /etc/wsl.conf

# Add these lines:
[boot]
systemd=true

# Save and exit, then restart WSL from PowerShell:
wsl --shutdown

After restarting your WSL instance, systemd should be running as PID 1, allowing normal systemctl commands to work.

4. Solutions for Linux Systems Without Systemd

Some specialized or older distributions may use alternative init systems.

Identify Your Init System:

# Check what's running as PID 1
ps -p 1

# Or examine the symbolic link
ls -l /sbin/init

Use the Appropriate Commands:

• For SysVinit:

  sudo service nginx start
  sudo /etc/init.d/apache2 restart
  

• For Upstart:

  sudo initctl start mysql
  sudo status ssh
  

Troubleshooting and Verification

After implementing the appropriate solution for your environment, verify the changes:

# If you enabled systemd, check that it's running as PID 1
ps -p 1

# Try a basic systemctl command
systemctl status

Advanced Systemd Troubleshooting for Linux Administrators

If you’re still experiencing issues after trying the solutions above, consider these additional troubleshooting steps:

1. Verify systemd package installation:

   dpkg -l | grep systemd
   # or
   rpm -qa | grep systemd
   

2. Check systemd journal for error messages:

   journalctl -xb | grep systemd
   

3. Inspect system initialization order:

   systemd-analyze
   systemd-analyze blame
   

4. For containers using systemd, ensure the correct dependencies are mounted:

   # Essential for systemd
   -v /sys/fs/cgroup:/sys/fs/cgroup:ro
   -v /run:/run
   

The “System has not been booted with systemd” error typically indicates you’re working in an environment not designed for systemd usage. By understanding your specific environment and applying the appropriate solution from this guide, you can either properly enable systemd where supported or adapt your approach to work without it when necessary.

Remember: In containerized environments especially, following the “do one thing well” philosophy often leads to simpler, more maintainable systems than trying to force systemd into environments where it wasn’t intended to run.