Debian/Ubuntu: Failed to connect to bus и System has not been booted with systemd as init system

Ошибка Failed to connect to bus: No such file or directory или развёрнутое сообщение System has not been booted with systemd as init system (PID 1). Can't operate. в Debian и Ubuntu почти всегда означает одно: вы запускаете systemctl не в той среде, где он способен нормально работать.

На практике это происходит в chroot, контейнерах, WSL, rescue-режиме, live-системах и минимальных образах. Команда привычная, вводится на автомате, но текущая среда может вовсе не иметь запущенного systemd как процесса PID 1, а значит и управлять сервисами через systemctl просто нечем.

Хорошая новость в том, что в большинстве случаев система не сломана. Нужно не переустанавливать пакеты наугад, а сначала понять, кто у вас PID 1, есть ли рабочая системная шина и в каком режиме вы вообще сейчас администрируете систему.

Что именно означает эта ошибка

systemctl — это клиент для управления systemd. Чтобы он работал, должен одновременно выполняться минимум двух условий: сама система должна быть загружена через systemd, и у клиента должен быть доступ к системной шине.

Сообщение System has not been booted with systemd as init system буквально говорит, что процесс PID 1 — не systemd. Это типично для chroot, контейнера без полноценного init и старых либо не настроенных экземпляров WSL.

Сообщение Failed to connect to bus шире по смыслу. Оно может появляться, если systemd не запущен вовсе, если недоступен dbus, если отсутствуют нужные каталоги в /run или если вы вошли в изолированную среду без необходимых монтирований.

Самая частая ошибка в диагностике — пытаться чинить systemctl, хотя проблема не в нём, а в том, что текущая среда не предполагает работу systemd вообще.

Первичная диагностика: что проверить в первую очередь

Перед любыми изменениями посмотрите, кто запущен как PID 1, и есть ли признаки нормальной работы системной шины.

ps -p 1 -o pid,comm,args=
readlink -f /proc/1/exe
cat /proc/1/comm
systemctl --version

Если в выводе вы видите systemd, значит хотя бы формально система загружена через него. Если там bash, sh, python, docker-init, tini или что-то подобное, это уже сильный индикатор, что вы не в обычной загруженной системе Debian/Ubuntu.

Дальше проверьте runtime-каталоги и сокет системной шины:

ls -ld /run /run/systemd /run/dbus
ls -l /run/dbus/system_bus_socket
busctl status

Если busctl тоже не может связаться с шиной, значит проблема почти наверняка в окружении, а не в конкретной команде systemctl.

Сценарий 1: вы в chroot, и это нормальное поведение

chroot подменяет корень файловой системы, но не создаёт полноценную новую загрузку. Внутри такого окружения обычно нет собственного PID 1 и нет запущенного systemd. Поэтому попытка выполнить systemctl restart ssh или systemctl status nginx там закономерно заканчивается ошибкой.

Типичный сценарий выглядит так:

mount /dev/sda2 /mnt
chroot /mnt /bin/bash
systemctl restart ssh

Здесь система не обязана уметь запускать сервисы. Задача chroot в другом: правка конфигов, работа с пакетами, обновление initramfs, восстановление загрузчика, сети, паролей и подготовка системы к следующей нормальной загрузке.

Чтобы пакетные операции в chroot проходили предсказуемее, лучше заранее сделать базовые монтирования:

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt /bin/bash

Это не сделает systemd процессом PID 1, но избавит от части сопутствующих проблем при работе с пакетами и служебными утилитами.

Если нужно не запустить сервис прямо сейчас, а включить его на следующую загрузку, иногда помогает работа с файловым состоянием юнитов:

systemctl --root=/mnt enable nginx

Важно: такой режим подходит для enable и похожих операций, но не для реального start, restart или полноценного status.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Сценарий 2: контейнер Debian/Ubuntu без systemd

Во многих контейнерах Debian и Ubuntu отсутствие рабочего systemctl — не неисправность, а архитектурная норма. Контейнер обычно запускает один основной процесс приложения, а не целую init-систему.

Проверить контейнерную среду можно так:

cat /proc/1/cgroup
tr '\0' '\n' < /proc/1/environ | grep -i container
hostnamectl

Если это Docker, Podman, LXC или похожий рантайм, не пытайтесь насильно переносить в контейнер модель управления классическим сервером. Вместо systemctl restart обычно используют перезапуск самого контейнера, запуск процесса напрямую или специальный supervisor, если он действительно нужен.

Подход тут простой:

• для обычного контейнера не ожидайте полноценной работы systemd;
• управляйте жизненным циклом контейнера снаружи;
• запускайте основное приложение как foreground-процесс;
• не усложняйте образ без реальной необходимости.

Если же у вас именно системный контейнер, где systemd должен работать осознанно, тогда уже проверяют поддержку cgroup, capabilities, нужные монтирования и модель запуска. Это отдельная задача, а не обычный случай контейнера.

Для сервисов и фоновых процессов в полноценной системе может пригодиться статья про выбор между Supervisor и systemd для воркеров: она помогает понять, когда init-система действительно нужна, а когда нет.

Сценарий 3: WSL и отсутствие systemd

WSL — одна из самых частых сред, где администратор видит сообщение System has not been booted with systemd as init system. Исторически дистрибутивы Debian/Ubuntu под WSL запускались без systemd, поэтому systemctl там не работал по определению.

В современных версиях WSL поддержку systemd можно включить, но это зависит от версии платформы и настроек дистрибутива. Сначала убедитесь, что вы действительно находитесь в WSL:

uname -a
cat /proc/version
ps -p 1 -o comm=

Если PID 1 не равен systemd, а вам нужен нормальный systemctl, проверьте конфигурацию /etc/wsl.conf:

[boot]
systemd=true

После изменения конфигурации недостаточно просто закрыть окно терминала. Экземпляр WSL нужно полностью завершить и запустить заново, иначе вы продолжите работать в старой сессии.

Если же systemd в WSL вам не нужен, не стоит строить рабочий процесс вокруг systemctl. Для локальной разработки часто достаточно запуска процессов напрямую.

Сценарий 4: rescue, live ISO, recovery shell

В rescue-среде или live-системе ошибка Failed to connect to bus тоже чаще всего ожидаема. Вы можете видеть файловую систему установленной Debian/Ubuntu, но это ещё не значит, что вошли именно в неё как в полноценно загруженную ОС.

Практически это означает простое правило: различайте работу с файлами установленной системы и работу внутри реально запущенной системы.

• Если вы исправляете загрузчик, сеть, конфиги или пакеты, вам часто достаточно монтирований и chroot.
• Если вы хотите проверять состояние сервисов через systemctl, это обычно нужно делать уже после нормальной загрузки установленной ОС.

В rescue-сценариях типичный порядок действий такой:

1. Смонтировать корневой раздел и при необходимости /boot или /boot/efi.
2. Сделать bind-монтирования /dev, /proc, /sys, /run.
3. Войти в chroot.
4. Исправить конфигурацию, пакет или загрузчик.
5. Перезагрузиться в обычную систему и уже там проверять сервисы.

Сценарий 5: systemd запущен, но проблема в dbus

Бывает и более интересная ситуация: система действительно загружена через systemd, но systemctl всё равно жалуется на bus. Тогда уже есть смысл проверять состояние dbus, сокетов в /run и журналы.

Начните с базовой проверки:

ps -p 1 -o comm=
systemctl is-system-running
systemctl status dbus
journalctl -b -u dbus --no-pager

Если PID 1 — это systemd, а dbus не стартует, смотрите в такие направления:

• проблемы с каталогами в /run;
• повреждённый или частично удалённый пакет dbus;
• сбой после неудачного обновления;
• ошибки прав доступа;
• заполненный диск или inode.

Для быстрой диагностики пакетов и логов в Debian/Ubuntu подойдут такие команды:

dpkg -l | grep '^ii' | grep dbus
apt-cache policy dbus systemd
journalctl -b --no-pager | grep -Ei 'dbus|systemd|bus'
df -h
df -i

Переустанавливать пакеты имеет смысл только после того, как вы исключили chroot, контейнер и WSL без включённого systemd:

apt update
apt install --reinstall dbus systemd

Если вы хотите глубже разобраться с эксплуатацией systemd на сервере, полезно дополнительно посмотреть материал про усиление безопасности сервисов средствами systemd.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Почему service иногда работает, а systemctl нет

Это классический источник путаницы. Команда service в Debian/Ubuntu — совместимый интерфейс. В зависимости от среды и конкретного сервиса она может обращаться либо к init-скриптам из /etc/init.d, либо к механизмам systemd.

Из-за этого возникает эффект: systemctl уже не работает, а service nginx status ещё показывает хоть что-то. Это не означает, что systemd исправен. Это лишь говорит, что у сервиса есть совместимый путь управления или остатки старой init-модели.

Если service частично работает, а systemctl нет, это не отменяет проблему. Скорее наоборот: подсказывает, что вы находитесь в промежуточной или нестандартной среде.

Как действовать правильно в зависимости от среды

Обычная установленная система

Проверьте, что PID 1 — это systemd. Если да, разбирайтесь с dbus, /run, журналами journalctl, диском и состоянием пакетов. Здесь ошибка уже считается неисправностью, а не нормой.

chroot

Не пытайтесь запускать сервисы через systemctl. Используйте chroot для ремонта системы и проверяйте сервисы после обычной загрузки.

Контейнер

Не ждите, что systemctl обязан работать. Управляйте контейнером снаружи и запускайте приложение напрямую.

WSL

Либо корректно включайте поддержку systemd, либо изначально стройте процесс без него. Смешанный подход обычно приводит к лишней путанице.

Rescue или live-среда

Сосредоточьтесь на восстановлении файловой системы и конфигурации, а не на попытках перезапускать сервисы внутри аварийной оболочки.

Мини-чеклист диагностики

1. Проверьте, кто является PID 1.
2. Определите среду: обычная система, chroot, контейнер, WSL или rescue.
3. Проверьте наличие /run/dbus/system_bus_socket.
4. Если это нормальная загрузка, посмотрите systemctl is-system-running и журналы.
5. Не переустанавливайте systemd, пока не исключили неподходящее окружение.
6. В chroot не пытайтесь полноценно перезапускать сервисы.
7. В контейнере используйте модель управления, соответствующую контейнеру, а не классическому серверу.

Вывод

Ошибки Failed to connect to bus и System has not been booted with systemd as init system в Debian/Ubuntu почти никогда не лечатся магической переустановкой пакетов. Намного чаще нужно правильно определить контекст: кто у вас PID 1, есть ли рабочий dbus и в какой среде выполняется команда.

Если это chroot, контейнер без init или rescue-режим, такое поведение обычно нормально. Если это WSL, проверьте, включён ли systemd. А если это полноценный сервер, где сервисы действительно должны жить под управлением systemd, тогда уже имеет смысл разбирать dbus, журналы и пакетную целостность.

Для проектов, где важно предсказуемое поведение init-системы, журналов и юнитов, лучше сразу использовать полноценную серверную среду на VDS или выбрать подходящий виртуальный хостинг, если задача не требует отдельного управления сервисами на уровне ОС.