Ошибка systemd not running: причины и решение в Linux

Что означает ошибка systemd not running

Ошибка systemd not running (или Failed to connect to bus: No such file or directory) возникает, когда менеджер служб и инициализации systemd не запущен или не отвечает в системе Linux. Это критическая проблема, так как systemd (PID 1) является основным процессом, который управляет всеми службами, mounts, сетевыми интерфейсами и т.д.

Типичные сообщения в терминале:

$ 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.

Ошибка чаще всего проявляется при попытках управлять службами через systemctl, читать логи journalctl или при автоматическом запуске графической среды.

Причины возникновения

1. Повреждение или потеря конфигурационных файлов systemd
   Файлы в /usr/lib/systemd/system/, /etc/systemd/system/ могли быть удалены, повреждены или перезаписаны с ошибками.
2. Некорректное завершение работы системы
   Внезапный сбой питания или kill -9 1 мог оставить systemd в неконсистентном состоянии, особенно если были активны критические юниты.
3. Недостаток ресурсов ядра или памяти
   Если systemd не может выделить память или создать необходимые сокеты (например, из-за переполнения /run), он может аварийно завершиться.
4. Конфликт с другими инициализационными системами
   Попытка установить SysVinit, OpenRC или upstart поверх systemd, либо ошибочный параметр ядра init= в GRUB.
5. Повреждение бинарного файла systemd
   Файл /usr/lib/systemd/systemd мог быть повреждён при обновлении, сбое диска или вредоносном ПО.
6. Проблемы с файловой системой /run или /dev
   Systemd использует tmpfs-раздел /run для сокетов и PID-файлов. Если этот раздел не смонтирован или переполнен, systemd не сможет создать свои сокеты.

Способ 1: Проверка и принудительный перезапуск systemd

Это безопасный первый шаг, который часто решает проблему при временных сбоях.

1. Проверьте, что PID 1 действительно systemd
   Выполните:

   ps -p 1 -o comm=
   

   
   Если вывод пустой или не systemd, значит, система загрузилась с другим init-системой или systemd упал.
2. Попробуйте перезагрузить демон systemd
   Важно: не используйте kill 1! Вместо этого:

   sudo systemctl daemon-reexec
   

   
   Эта команда заставляет systemd перечитать свои конфигурации и перезапустить демон, не прерывая текущие процессы (насколько это возможно).
3. Если команда недоступна, временно переключитесь на rescue-режим:
   • Перезагрузите машину.
   • В меню GRUB выберите Advanced options → Recovery mode.
   • В меню recovery выберите root (read-only) или fsck.
   • После получения root-доступа попробуйте:

     mount -o remount,rw /
     systemctl daemon-reexec
     

   • Затем reboot -f.
4. Проверьте статус после перезапуска:

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

Способ 2: Восстановление конфигурационных файлов systemd

Если перезапуск не помог, возможно, повреждены файлы конфигурации.

Для Debian/Ubuntu и производных:

# Переустановите пакет systemd, сохраняя конфиги
sudo apt update
sudo apt install --reinstall systemd

# Переконфигурируйте пакет
sudo dpkg-reconfigure systemd

# Перезагрузите
sudo reboot

Для RHEL/CentOS/Fedora:

# Проверьте целостность пакета
sudo rpm -V systemd

# Если есть отклонения, переустановите
sudo yum reinstall systemd   # CentOS 7
sudo dnf reinstall systemd   # CentOS 8+/Fedora

# После переустановки обновите initramfs
sudo dracut -f --regenerate-all   # RHEL/CentOS/Fedora с dracut
sudo update-initramfs -u          # Debian/Ubuntu с initramfs-tools

sudo reboot

Для Arch Linux:

sudo pacman -S systemd
sudo reboot

Способ 3: Проверка и восстановление раздела /run

Systemd использует /run (обычно tmpfs) для хранения сокетов и временных файлов. Если он переполнен или смонтирован с неверными опциями, systemd не сможет создать свои сокеты.

1. Проверьте, смонтирован ли /run как tmpfs:

   mount | grep ' /run '
   

   
   Ожидаемый вывод: tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=...). Если нет — смонтируйте:

   sudo mount -t tmpfs tmpfs /run
   

2. Проверьте свободное место:

   df -h /run
   

   
   Если место исчерпано (например, 100% использования), очистите временные файлы:

   sudo rm -rf /run/user/*   # временные файлы пользователей
   sudo rm -rf /run/log/*    # старые логи (осторожно!)
   

3. Убедитесь, что /run имеет правильные права:

   ls -ld /run
   

   
   Должно быть: drwxr-xr-x и владелец root:root. При необходимости:

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

4. Перезагрузите после этих действий, так как systemd должен пересоздать свои сокеты при старте.

Способ 4: Ручное восстановление через chroot (если система не загружается)

Если systemd не запускается даже в rescue-режиме, потребуется загрузка с LiveCD и chroot.

1. Загрузитесь с LiveCD (Ubuntu Live, SystemRescue и т.д.).
2. Определите раздел с вашей системой:

   lsblk -f
   

   Найдите раздел с ext4/xfs/btrfs, содержащий /.
3. Смонтируйте корневой раздел:

   sudo mount /dev/sdXY /mnt   # замените sdXY на ваш раздел, например sda2
   

4. Смонтируйте системные точки (если есть отдельный /boot, /var):

   sudo mount /dev/sdXZ /mnt/boot   # если раздел /boot отдельный
   

5. Скопируйте системные устройства и смонтируйте 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   # если /run отдельный
   

6. Перейдите в chroot:

   sudo chroot /mnt
   

7. Внутри chroot проверьте и переустановите systemd (как в Способе 2).
8. Выйдите и перезагрузитесь:

   exit
   sudo reboot
   

Способ 5: Проверка диска и журналов ядра

Если предыдущие способы не помогли, проблема может быть глубже — в оборудовании или ядре.

1. Проверьте SMART-статус диска (если подозреваете сбой диска):

   sudo smartctl -a /dev/sda   # замените sda на ваш диск
   

   
   Ищите ошибки SMART или FAILED.
2. Проверьте журналы ядра (kmsg) через serial console или netconsole
   Если systemd не запущен, стандартный journalctl недоступен. Можно попробовать:

   sudo cat /proc/kmsg | less   # требует прав root и может быть очень многострочным
   

   
   Или настройте netconsole для удалённого сбора логов.
3. Попробуйте загрузиться с older ядром
   В меню GRUB выберите Advanced options → предыдущую версию ядра. Если с older ядром systemd работает — проблема в новом ядре или модулях.
4. Обновите прошивку (BIOS/UEFI)
   Иногда ошибки инициализации оборудования приводят к падению systemd.

Профилактика

Чтобы избежать повторения ошибки:

1. Не редактируйте конфиги systemd вручную без бэкапа
   Всегда делайте копию перед изменениями:

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

2. После обновления systemd или ядра сразу перезагружайтесь
   Часто обновления systemd требуют перезагрузки для применения новых бинарников и конфигов.
3. Мониторьте место на /run
   Добавьте в crontab проверку:

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

4. Используйте стабильные версии дистрибутива для production-серверов
   Избегайте rolling-release дистрибутивов (например, Arch) на критичных серверах без тщательного тестирования.
5. Настройте redundant boot
   В GRUB оставьте как минимум две последние стабильные версии ядра, чтобы можно было откатиться.
6. Регулярно обновляйте систему, но не автоматически на production. Тестируйте обновления на staging-среде.
7. Используйте мониторинг (Zabbix, Prometheus) для отслеживания статуса PID 1 и ключевых служб. Пример check для systemd:

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