Failed to connect to system bus: No such file or directory Linux / DevOps

Failed to connect to system bus — Ошибка сокета D-Bus в systemd

Обновлено: 18.08.2026 · Официальная база знаний

Архитектура ошибки и симптомы сбоя

Сообщение «Failed to connect to system bus: No such file or directory» (или «Failed to get D-Bus connection: Operation not permitted») возникает при выполнении команд управления системой (systemctl, journalctl, hostnamectl). Ошибка означает, что клиентская утилита не обнаружила рабочий Unix-сокет системной шины по стандартному пути /run/dbus/system_bus_socket или /var/run/dbus/system_bus_socket. Это стандартная ситуация внутри минималистичных Docker-контейнеров, сред chroot или при аварийном падении службы dbus.socket.

Диагностическая таблица параметров сбоя

Параметр	Значение	Инженерный смысл сбоя
Socket Path	/run/dbus/system_bus_socket	Физический Unix Domain Socket системной шины сообщений.
Container Context	Docker / Podman / Chroot	Внутри изолированного контейнера без init-системы (PID 1) systemd и D-Bus отсутствуют.
dbus.socket	systemd Socket Unit	Юнит, слушающий сетевой сокет и автоматически поднимающий dbus.service.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Запуск и активация сокета D-Bus на хосте

# Запуск сокета и сервиса D-Bus:
sudo systemctl start dbus.socket
sudo systemctl start dbus.service

# Проверка наличия сокета:
ls -la /run/dbus/system_bus_socket

Сценарий 2: Управление службами внутри сред Chroot (Rescue Mode)

Внутри chroot-окружения прямое управление через systemctl невозможно без проброса шины. Используйте традиционные команды или флаги:

# Прямой вызов скриптов инициализации в chroot:
/etc/init.d/service_name restart

# Либо включение/отключение сервисов через создание симлинков:
systemctl enable service_name --root=/target_chroot_path

Сценарий 3: Решение проблемы внутри Docker-контейнеров

Стандартные контейнеры Docker не используют systemd в качестве PID 1:

# НЕ используйте systemctl внутри обычного контейнера!
# Запускайте сервис напрямую через бинарный файл в ENTRYPOINT/CMD:
# CMD ["nginx", "-g", "daemon off;"]

# Если systemd критически необходим в Docker (Systemd-in-Docker):
# Запускайте контейнер с флагом привилегий и монтированием cgroups:
docker run -d --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:rw my_systemd_image /sbin/init

Не работают утилиты управления внутри контейнеров или аварийных сред Rescue?
ITSTM настроит правильный lifecycle контейнеризированных приложений и интеграцию D-Bus в изолированных средах.

Практический опыт инженера: При сборке Docker-образов никогда не устанавливайте пакет systemd для запуска одного демона — используйте легковесные менеджеры процессов (tini, dumb-init, supervisord).

Частые вопросы (FAQ)

Почему systemctl не работает внутри стандартного Docker контейнера?

В Docker процессом PID 1 является ваше приложение (например, python или node), а не systemd. Без работающего systemd в качестве PID 1 команды systemctl и сокет D-Bus не функционируют.

Как пробросить D-Bus хоста внутрь контейнера?

Смонтируйте Unix-сокет при запуске контейнера: -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket.

Что делать, если каталог /run/dbus отсутствует?

Создайте его вручную и запустите демон: sudo mkdir -p /run/dbus && sudo dbus-daemon --system.

Как переопределить путь к сокету D-Bus для утилит?

Задайте переменную окружения перед вызовом команды: export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket.