4

A sudo user named my-host is getting the following error message when trying to reload systemctl on an Amazon Linux 2 EC2 image.

[my-host@ip-12-3-4-56 ~]$ systemctl --user daemon-reload
Failed to get D-Bus connection: Connection refused

What specifically needs to be done to resolve and remove this error?

The other postings I have found on this error message are either related to Debian with an apt-get solution that does not apply here, or are related to Docker images, which also do not apply here.

If the problem has to do with user privileges, what would need to be done to remediate the problem?

This machine has a requirement that some systemctl commands like this must not run as sudo.

TRY AGAIN WITH DIRECT LOGIN USER PER @Stewart's and @JdeBP's SUGGESTIONS:

We then tried using a sudo user that has direct ssh ability from the outside world, but still got the following results:

[ssh-login-user@ip-12-3-4-567 ~]$ systemctl --user daemon-reload
Failed to get D-Bus connection: No such file or directory
[ssh-login-user@ip-12-3-4-567 ~]$ echo $XDG_RUNTIME_DIR $UID
/run/user/1001 1001
[ssh-login-user@ip-12-3-4-567 ~]$ systemctl --user status
Failed to get D-Bus connection: No such file or directory
[ssh-login-user@ip-12-3-4-567 ~]$ sudo install -d -o ssh-login-user /run/user/`id -u ssh-login-user`
[sudo] password for ssh-login-user:
[ssh-login-user@ip-12-3-4-567 ~]$ sudo systemctl start user@`id -u ssh-login-user`
Failed to start [email protected]: Unit not found.
[ssh-login-user@ip-12-3-4-567 ~]$ sudo -u ssh-login-user DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/`id -u ssh-login-user`/bus systemctl --user
Failed to get D-Bus connection: No such file or directory

To confirm the state of systemctl, we then also did the following, which reported one degraded service as follows:

● ip-12-3-4-567.aws-region-n.compute.internal
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Wed 2020-10-28 23:40:50 UTC; 7min ago
   CGroup: /
           ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
           ├─user.slice
           │ └─user-1001.slice
           │   └─session-2.scope
           │     ├─18736 sshd: ssh-login-user [priv]
           │     ├─18738 sshd: ssh-login-user@pts/0
           │     ├─18739 -bash
           │     ├─18792 sudo systemctl status
           │     └─18793 systemctl status
           └─system.slice
             ├─rngd.service
             │ └─2692 /sbin/rngd -f
             ├─amazon-ssm-agent.service
             │ ├─3810 /usr/bin/amazon-ssm-agent
             │ └─4428 /usr/bin/ssm-agent-worker
             ├─libstoragemgmt.service
             │ └─2694 /usr/bin/lsmd -d
             ├─systemd-udevd.service
             │ └─1968 /usr/lib/systemd/systemd-udevd
             ├─system-serial\x2dgetty.slice
             │ └─[email protected]
             │   └─3273 /sbin/agetty --keep-baud 115200,38400,9600 ttyS0 vt220
             ├─chronyd.service
             │ └─2685 /usr/sbin/chronyd
             ├─auditd.service
             │ └─2646 /sbin/auditd
             ├─systemd-journald.service
             │ └─1931 /usr/lib/systemd/systemd-journald
             ├─atd.service
             │ └─3239 /usr/sbin/atd -f
             ├─sshd.service
             │ └─3486 /usr/sbin/sshd -D
             ├─crond.service
             │ └─3529 /usr/sbin/crond -n
             ├─gssproxy.service
             │ └─2711 /usr/sbin/gssproxy -D
             ├─rsyslog.service
             │ └─3229 /usr/sbin/rsyslogd -n
             ├─rpcbind.service
             │ └─2683 /sbin/rpcbind -w
             ├─network.service
             │ ├─2919 /sbin/dhclient -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid eth0
             │ └─3034 /sbin/dhclient -6 -nw -lf /var/lib/dhclient/dhclient6--eth0.lease -pf /var/run/dhclient6-eth0.pid eth0
             ├─lvm2-lvmetad.service
             │ └─1953 /usr/sbin/lvmetad -f
             ├─postfix.service
             │ ├─3177 /usr/libexec/postfix/master -w
             │ ├─3178 pickup -l -t unix -u
             │ └─3179 qmgr -l -t unix -u
             ├─acpid.service
             │ └─3456 /usr/sbin/acpid
             ├─dbus.service
             │ └─2681 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
             ├─system-getty.slice
             │ └─[email protected]
             │   └─3274 /sbin/agetty --noclear tty1 linux
             └─systemd-logind.service
               └─2686 /usr/lib/systemd/systemd-logind

What else can we do to resolve this problem?

ANSWER: We decided to continue running systemctl as sudo and instead to just specify the user in the .service file so that the service will run as the specified user and not as root or sudo. We chose this approach because the answers below did not resolve the problem.

6
  • 1
    I just reproduced this on a debian machine with a secondary user. At first I thought maybe it was because ~/.config/systemd/user/ didn't exist, but that doesn't appear to the be the problem. It works fine with my primary user.
    – Stewart
    Oct 23, 2020 at 6:50
  • @Stewart This is not Debian. This is Amazon Linux 2, which is a child of RHEL. Also, this is a secondary user not the primary user, but we are free to configure the secondary user any we need to if you have suggestions how.
    – CodeMed
    Oct 23, 2020 at 7:15
  • 2
    True, but I reproduced it on debian. I thought it was worth mentioning that it appears to be independent of distros
    – Stewart
    Oct 23, 2020 at 7:16
  • Related questions are unix.stackexchange.com/q/423632/5132 and unix.stackexchange.com/q/431896/5132 .
    – JdeBP
    Oct 23, 2020 at 7:23
  • @JdeBP This OP specifies Amazon Linux 2, which is derived from RHEL.
    – CodeMed
    Oct 23, 2020 at 7:28

7 Answers 7

5

Stewart is right for the XDG_RUNTIME_DIR and UID mismatch using the su command from another account.

Sometimes also, the user manager instance is not running for the user UID (i.e [email protected]).

Therefore, you get this error message:

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

Check that these exists:

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

If so, start the user manager instance for USER_UID as root:

systemctl start user@USER_UID.service

Otherwise read more in the [email protected] man page.

Some useful links:

3
  • On a Ubuntu system, after I had killed all processes for a user they were no longer able to start a GUI session like VNC or XRDP. I didn't have any user things under /usr/lib/systemd/system/ but simply starting the user@<UID>.service as mentioned on this answer was the solution I needed. Thank you! Nov 14, 2023 at 20:16
  • XRDP gave two error messages: Unable to contact settings server Failed to connect to socket /run/user/1001/bus: Connection refused Unable to load a failsafe session Unable to determine failsafe session name. Possible causes: xfconfd isn't running (D-Bus setup problem); environment variable $XDG_CONFIG_DIRS is set incorrectly (must include "/etc"), or xfce4-session is installed incorrectly. Nov 14, 2023 at 20:17
  • Tiger VNC gave the cryptic error messages: vncserver: Failed command '/etc/X11/Xvnc-session': 256! ... XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1" after 173 requests (173 known processed) with 0 events remaining. Killing Xtigervnc process ID 58953... which seems to be deadlocked. Using SIGKILL! Nov 14, 2023 at 20:19
2

How are you logging in as my-host?

If it's with su, I found that /run/user/$UID isn't created and XDG_RUNTIME_DIR isn't updated.

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

Because $XDG_RUNTIME_DIR isn't changed, systemd is trying to connect to the user runtime of your original user which my-host doesn't have permissions for.

Per the 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,

The answer is to login as my-host with a totally fresh session. Ways to do that:

  1. reboot
  2. Exit to your display manager and login again
  3. machinectl login
  4. ssh [email protected]

I've seen other posts which do things like mkdir /run/user/$(id -u) and manually set environment variables such as XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS, but the most reliable way is to simply change how you login. A clean login will do all of that for you.

4
  • $XDG_RUNTIME_DIR is not defined for my-host in the EC2 instance in question. Since Ansible is being used to create my-host, it may take a little time to get remote login set up for my-host. Our model was for Ansible to login as user and then change to become my-host. I will be able to work on this Monday and get back to you with more results. Thank you.
    – CodeMed
    Oct 24, 2020 at 0:48
  • We just added the results of your suggestion to the OP. We are happy to use a user with remote login abilities per your suggestion, but this still leaves the problem shown above. What else should we try?
    – CodeMed
    Oct 28, 2020 at 22:26
  • Just added additional updates to the OP. Do you have more suggestions?
    – CodeMed
    Oct 29, 2020 at 20:36
  • 1
    Nothing worked for me, until I login as target user via ssh. anything (login included) started with "su"/"sudo" -u etc will not work at all. then I just loginctl enable-linger $newuser. luckily It works after reboot, It seems just one-time login is enough.
    – Ben
    Oct 8, 2022 at 10:29
2

The other answer I wrote is valid for cases where your user has a login. Your comment to that answer suggested that you don't have remote login. It sounds like my-host is a system user.

The reasons we'd often want to use the user bus is so that the user can control their own units with systemctl and review their own logs with journalctl. If the user is a system user with no login, then there is no one to control the bus and so it doesn't really make sense.

Instead of using the systemd user bus, consider using the systemd system bus.

If you need to run an application as a specific user, just add User= to your [Service] section. Then it will run as part of the system bus, but execute as your unprivileged system user. Maybe that's what you were trying to do with systemctl --user in the first place.

If you are running an application which includes <systemd/sd-bus.h> or a script which calls systemctl and you are want to run that as my-host, it's still possible to grant access to the system bus without sudo. This requires some polkit rules described in this answer or in this answer. If you also want to use the system's journal, add my-host to group systemd-journal or follow instructions here.

0

My solution to this is rooted in the accidental removal of dbus. Reinstalling it and making sure it's running solved this for me.

sudo apt install dbus
sudo systemctl start dbus

After this, all the systemd tools started working again, timedatectl, localectl, and so on.

4
  • As the OP mentioned, he is not running a variant of Debian, so apt will not be present. Nov 3, 2022 at 19:52
  • 1
    The OP also solved this over a year ago, as did I (albeit with a different approach). For futher readers of this question and answers, this is still useful. As for non-debian systems, replace 'apt' with 'yum' or 'dnf' or other package managers.
    – antonyh
    Nov 7, 2022 at 12:09
  • 1
    I'm just being a pedant, please ignore me :-) Also, I haven't checked 'other' package managers, but it's possible that they name the package differently... Nov 10, 2022 at 15:39
  • Hehe, all good. Pedantry is an important quality when dealing with *nix in my experience. Anyhow, I thought this might amuse you xkcd.com/1654 :-)
    – antonyh
    Nov 11, 2022 at 15:35
0

You need enable systemctl control to your user...

first get your UID:

id 

example output:
uid=1001(ocp) gid=1001(ocp) groups=1001(ocp),988(libvirt)

then set your perm with sudo or root:

sudo machinectl shell --uid = 1001

done, now try again.

0

Failed to connect to bus: No such file or directory

  1. Run systemctl daemon-reload as root user

    [root@Red-Hat-8_103 ~]# systemctl daemon-reload
    
  2. Generate the systemd unit file again in /home/student/.config/systemd/user/ as student user (you can login as per your username)

    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. Now run systemctl --user daemon-reload

    [student@Red-Hat-8_103 user]$ systemctl --user daemon-reload
    
1
  • Please provide additional details in your answer. As it's currently written, it's hard to understand your solution.
    – Community Bot
    Sep 4, 2021 at 23:01
-2

Your services are not running first reboot for Linux systems use:

reboot

or

reboot -f

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .