systemd Not Running Error: Causes and Solutions in Linux

What the "systemd not running" Error Means

The systemd not running error (or Failed to connect to bus: No such file or directory) occurs when the systemd service and init manager is not running or unresponsive in a Linux system. This is a critical issue because systemd (PID 1) is the primary process that manages all services, mounts, network interfaces, etc.

Typical messages in the terminal:

$ systemctl status sshd
Failed to connect to bus: No such file or directory

$ journalctl
Cannot connect to system bus: No such file or directory

$ sudo systemctl restart network
System has not been booted with systemd as init system (PID 1). Can't operate.

The error most commonly appears when attempting to manage services via systemctl, read journalctl logs, or during automatic startup of a graphical environment.

Common Causes

1. Corruption or loss of systemd configuration files
   Files in /usr/lib/systemd/system/ and /etc/systemd/system/ may have been deleted, corrupted, or overwritten with errors.
2. Improper system shutdown
   A sudden power failure or kill -9 1 could leave systemd in an inconsistent state, especially if critical units were active.
3. Insufficient kernel resources or memory
   If systemd cannot allocate memory or create necessary sockets (e.g., due to a full /run partition), it may crash.
4. Conflict with other init systems
   Attempting to install SysVinit, OpenRC, or upstart over systemd, or an incorrect kernel parameter init= in GRUB.
5. Corrupted systemd binary
   The /usr/lib/systemd/systemd file may be damaged due to an update, disk failure, or malware.
6. Problems with the /run or /dev filesystem
   Systemd uses the tmpfs partition /run for sockets and PID files. If this partition is not mounted or is full, systemd cannot create its sockets.

Method 1: Check and Force-Restart systemd

This is a safe first step that often resolves the issue after temporary failures.

1. Verify that PID 1 is actually systemd
   Run:

   ps -p 1 -o comm=
   

   
   If the output is empty or not systemd, the system booted with a different init system or systemd has crashed.
2. Try to restart the systemd daemon
   Important: Do not use kill 1! Instead:

   sudo systemctl daemon-reexec
   

   
   This command forces systemd to reload its configurations and restart the daemon without interrupting current processes (as much as possible).
3. If the command is unavailable, temporarily switch to rescue mode:
   • Reboot the machine.
   • In the GRUB menu, select Advanced options → Recovery mode.
   • In the recovery menu, select root (read-only) or fsck.
   • After gaining root access, try:

     mount -o remount,rw /
     systemctl daemon-reexec
     

   • Then run reboot -f.
4. Check the status after restarting:

   systemctl list-units --type=service --state=running
   

Method 2: Restore systemd Configuration Files

If restarting didn't help, configuration files may be corrupted.

For Debian/Ubuntu and derivatives:

# Reinstall the systemd package while preserving configs
sudo apt update
sudo apt install --reinstall systemd

# Reconfigure the package
sudo dpkg-reconfigure systemd

# Reboot
sudo reboot

For RHEL/CentOS/Fedora:

# Verify package integrity
sudo rpm -V systemd

# If there are deviations, reinstall
sudo yum reinstall systemd   # CentOS 7
sudo dnf reinstall systemd   # CentOS 8+/Fedora

# After reinstall, update initramfs
sudo dracut -f --regenerate-all   # RHEL/CentOS/Fedora with dracut
sudo update-initramfs -u          # Debian/Ubuntu with initramfs-tools

sudo reboot

For Arch Linux:

sudo pacman -S systemd
sudo reboot

Method 3: Check and Restore the /run Partition

Systemd uses /run (typically tmpfs) for sockets and temporary files. If it is full or mounted with incorrect options, systemd cannot create its sockets.

1. Check if /run is mounted as tmpfs:

   mount | grep ' /run '
   

   
   Expected output: tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=...). If not — mount it:

   sudo mount -t tmpfs tmpfs /run
   

2. Check free space:

   df -h /run
   

   
   If space is exhausted (e.g., 100% usage), clean temporary files:

   sudo rm -rf /run/user/*   # user temporary files
   sudo rm -rf /run/log/*    # old logs (be careful!)
   

3. Ensure /run has correct permissions:

   ls -ld /run
   

   
   Should be: drwxr-xr-x and owned by root:root. If needed:

   sudo chmod 755 /run
   sudo chown root:root /run
   

4. Reboot after these actions, as systemd must recreate its sockets on startup.

Method 4: Manual Recovery via chroot (if system doesn't boot)

If systemd fails to start even in rescue mode, you'll need to boot from a LiveCD and use chroot.

1. Boot from a LiveCD (Ubuntu Live, SystemRescue, etc.).
2. Identify the partition containing your system:

   lsblk -f
   

   Find the partition with ext4/xfs/btrfs containing /.
3. Mount the root partition:

   sudo mount /dev/sdXY /mnt   # replace sdXY with your partition, e.g., sda2
   

4. Mount system mount points (if separate /boot, /var exist):

   sudo mount /dev/sdXZ /mnt/boot   # if /boot is separate
   

5. Copy system devices and mount proc/sys/run:

   sudo mount --bind /dev /mnt/dev
   sudo mount --bind /proc /mnt/proc
   sudo mount --bind /sys /mnt/sys
   sudo mount --bind /run /mnt/run   # if /run is separate
   

6. Enter chroot:

   sudo chroot /mnt
   

7. Inside chroot, check and reinstall systemd (as in Method 2).
8. Exit and reboot:

   exit
   sudo reboot
   

Method 5: Disk and Kernel Log Checks

If previous methods didn't help, the issue may be deeper—hardware or kernel-related.

1. Check disk SMART status (if suspecting disk failure):

   sudo smartctl -a /dev/sda   # replace sda with your disk
   

   
   Look for SMART errors or FAILED.
2. Check kernel logs (kmsg) via serial console or netconsole
   If systemd isn't running, standard journalctl is unavailable. You can try:

   sudo cat /proc/kmsg | less   # requires root and can be very verbose
   

   
   Or configure netconsole for remote log collection.
3. Try booting with an older kernel
   In the GRUB menu, select Advanced options → a previous kernel version. If systemd works with an older kernel—the issue is with the new kernel or modules.
4. Update firmware (BIOS/UEFI)
   Sometimes hardware initialization errors cause systemd to crash.

Prevention

To avoid recurrence:

1. Never edit systemd configs manually without a backup
   Always copy before changes:

   sudo cp /etc/systemd/system/myservice.service /etc/systemd/system/myservice.service.bak
   

2. Reboot immediately after systemd or kernel updates
   Systemd updates often require a reboot to apply new binaries and configs.
3. Monitor /run space
   Add a cron check:

   */30 * * * * df -h /run | grep -v Filesystem | awk '{if ($5+0 > 90) print "WARNING: /run usage "$5}' | wall
   

4. Use stable distribution versions for production servers
   Avoid rolling-release distributions (e.g., Arch) on critical servers without thorough testing.
5. Configure redundant boot
   In GRUB, keep at least two recent stable kernel versions to allow rollback.
6. Update regularly, but not automatically on production
   Test updates in a staging environment first.
7. Use monitoring (Zabbix, Prometheus) to track PID 1 and key service status. Example check for systemd:

   systemctl is-system-running --quiet || echo "SYSTEMD DOWN"