Не удалось получить D -Соединение с шиной :Отказ в соединении

Другой ответ, который я написал, действителен для случаев, когда у вашего пользователя есть логин. Ваш комментарий к этому ответу предполагает, что у вас нет удаленного входа в систему. Похоже, my-host— системный пользователь.

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

Вместо использования пользовательской шины systemd рассмотрите возможность использования системной шины systemd.

Если вам нужно запустить приложение от имени конкретного пользователя, просто добавьте User=в раздел [Service]. Тогда он будет работать как часть системной шины, но выполняться как непривилегированный системный пользователь. Может быть, это то, что вы пытались сделать с systemctl --userв первую очередь.

Если вы запускаете приложение, которое включает <systemd/sd-bus.h>или сценарий, который вызывает systemctl, и вы хотите запустить его как my-host, все еще можно предоставить доступ к системной шине без sudo. Для этого требуются некоторые правила polkit , описанные в этом ответе или в этом ответе . Если вы также хотите использовать journalсистемы, добавьте my-hostв группу systemd-journalили следуйте инструкциям здесь .

Стюарт прав в отношении несоответствия XDG_RUNTIME_DIRи UIDпри использовании команды suиз другой учетной записи.

Иногда экземпляр диспетчера пользователей не работает для пользователя UID(, т.е. user@1000.service ).

Таким образом, вы получаете это сообщение об ошибке:

Failed to get D-Bus connection: No such file or directory

Убедитесь, что они существуют:

ls -l /usr/lib/systemd/system/user{,-runtime-dir}@.service

Если это так, запустите экземпляр диспетчера пользователей для USER _UID как root:

systemctl start user@USER_UID.service

В противном случае читайте подробнее наhttps://www.freedesktop.org/software/systemd/man/user@.service.html

Несколько полезных ссылок:

https://serverfault.com/a/1026914

https://bugs.centos.org/view.php?id=8767

Как вы входите в систему как my-host?

Если это с su, я обнаружил, что /run/user/$UIDне создается и XDG_RUNTIME_DIRне обновляется.

user ~ $ echo $XDG_RUNTIME_DIR $UID
/run/user/1000 1000

user ~ $ su my-host

my-host ~ $ echo $XDG_RUNTIME_DIR $UID
/run/user/1000 1001                     <-- Mismatch here! 

my-host ~ $ systemctl --user status
Failed to connect to bus: Permission denied

Поскольку $XDG_RUNTIME_DIRне изменен, systemd пытается подключиться к пользовательской среде выполнения вашего исходного пользователя, для которого my-hostнет разрешений.

Согласно systemd devs:

"su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session. A new login session has a very well defined, pristine setup, not inheriting anything from any other session, but this is really not the case for "su" uid changes: most of the execution environment is inherited over, in numerous and non-obvious ways, for example MAC contexts, audit contexts, cgroup contexts, namespace contexts, scheduling, timer granularity,

Ответ заключается в том, чтобы войти в систему как my-hostс совершенно новым сеансом. Как это сделать:

1. перезагрузка
2. Выйдите из диспетчера дисплеев и снова войдите в систему
3. machinectl login
4. ssh my-host@127.0.0.1

Я видел другие сообщения, которые делают такие вещи, как mkdir /run/user/$(id -u)и вручную устанавливают переменные среды, такие как XDG_RUNTIME_DIRи DBUS_SESSION_BUS_ADDRESS, но самый надежный способ — просто изменить способ входа в систему. Чистый логин сделает все это за вас.

Окончательное решение:-(100% работает):-Не удалось подключиться к шине :Нет такого файла или каталога

1. Запустите systemctl daemon-reloadот имени пользователя root

   [root@Red-Hat-8_103 ~]# systemctl daemon-reload
   

2. Снова сгенерируйте файл модуля systemd в /home/student/.config/systemd/user/как студентuser(вы можете войти под своим именем пользователя)

   student@Red-Hat-8_103 user]$ podman generate systemd --name httpd_server_site1 --files /home/student/.config/systemd/user/container-httpd_server_site1.service
   

3. Теперь запуститеsystemctl --user daemon-reload

   [student@Red-Hat-8_103 user]$ systemctl --user daemon-reload
   

Мое решение этой проблемы основано на случайном удалении dbus. Переустановка и проверка работоспособности решили эту проблему для меня.

sudo apt install dbus
sudo systemctl start dbus

После этого все инструменты systemd снова заработали, timedatectl, localectlи так далее.