Failed to connect to bus: No such file or directory
#Откуда берётся ошибка
Команды systemctl --user, loginctl, busctl, gsettings и многие графические утилиты общаются с шиной D-Bus через сокет. Для пользовательской сессии он лежит в /run/user/<UID>/bus, а путь передаётся переменными окружения XDG_RUNTIME_DIR и DBUS_SESSION_BUS_ADDRESS. Если пользователь вошёл не через полноценную сессию, например через su без -l, sudo -u, cron, ssh с отключённым PAM, контейнер или WSL без systemd, каталог /run/user/<UID> отсутствует либо переменные не заданы. Отсюда No such file or directory.
#Типичные сценарии
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| su или sudo -u без сессииНет окружения пользователя. | Переменные пусты. | Используйте sudo -iu пользователь или machinectl shell пользователь@. |
ssh без PAM-сессииОтключён UsePAM. | Нет каталога /run/user. | Включите UsePAM yes в sshd_config и перезапустите sshd. |
| cron или скриптНет сессии. | Скрипт падает по cron, а руками работает. | Задайте переменные в начале скрипта или используйте системную службу вместо пользовательской. |
| Docker-контейнерНет systemd внутри. | PID 1 не systemd. | Запускайте службы командой напрямую или используйте образ с systemd. |
| WSLНет systemd. | PID 1 — init. | Включите systemd в /etc/wsl.conf: [boot] и systemd=true, затем wsl --shutdown. |
| Сессия закрытаСлужба пользователя остановлена после выхода. | После выхода сервисы пропали. | loginctl enable-linger. |
#Диагностика
- Проверьте переменныеВ терминале Linux выполните
id -u,echo "$XDG_RUNTIME_DIR"иecho "$DBUS_SESSION_BUS_ADDRESS". ОшибкаFailed to connect to busчасто относится кsystemctl --user, запущенному без настоящей пользовательской сессии; сначала уточните, использована ли команда с--user, подsudoили внутри контейнера. - Проверьте, существует ли сокетДля обычной пользовательской сессии проверьте
ls -ld /run/user/$(id -u)и наличие сокета/run/user/$(id -u)/bus. Если каталог или сокет отсутствует, не создавайте их вручную и не назначайте всем права 777: их обычно создаёт менеджер пользовательских сессий systemd/logind. - Проверьте, запущен ли systemdВыполните
ps -p 1 -o comm=иsystemctl --version. Если PID 1 неsystemd(например, контейнер без systemd или WSL без соответствующей настройки),systemctlне сможет управлять сервисами как на обычном хосте. Используйте способ запуска служб, предусмотренный именно этой средой. - Проверьте, есть ли сессияКомандой
loginctl list-sessionsпроверьте, есть ли ваша пользовательская сессия, и посмотритеloginctl user-status имя_пользователя. Вход черезsudo -uне всегда создаёт полноценную logind-сессию, поэтомуsystemctl --userможет не найти шину. Попробуйте войти обычным SSH под нужным пользователем. - Определите способ входаДля пользовательских служб используйте учётную запись их владельца, а для системных —
sudo systemctl status имя.serviceбез--user. Временноеexport XDG_RUNTIME_DIR=...не создаст отсутствующий сокет и может привести к подключению к чужой шине; для постоянной фоновой службы настройку linger согласуйте с администратором системы. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
Если вам нужна системная, а не пользовательская служба, запускайте команды без --user и с sudo: sudo systemctl status имя. Для пользовательских служб в контейнерах или на серверах без сессии надёжнее оформить их как системные юниты с параметром User= в файле службы.