16

Can one user, or maybe root, control another user's user level systemd services?

I've tried sudo -u <some user> systemctl --user restart <some service>, but it complains about dbus: Failed to get D-Bus connection: Connection refused.

4 Answers 4

13

I had the same problem when I remotely logged into my gentoo box via ssh. In my case this was because the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS environment variables were missing. Run the following commands and try again:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

If this helps, you can put those commands into your .bashrc. I guess there must be a more elegant solution than .bashrc but that depends on your distro.

Here is where I found that solution.

Edit:

logged in as root, I managed to successfully run systemctl --user as another user using su as follows:

su -c 'XDG_RUNTIME_DIR="/run/user/$UID" DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus" systemctl --user status' username

or using sudo (note, I had to explicitely add the respective users UID (1000) to the path '/run/user/', but if you are running it from a bash script you can use $SUDO_UID instead):

sudo -u username XDG_RUNTIME_DIR="/run/user/1000" DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus" systemctl --user status
1
  • 2
    I have exactly that in /etc/profile.d/dbus.sh. I guess sudo needs those whitelisted, because it clears the environment by default. I'm not sure if it will just transfer the current user's runtime dir, though.
    – mkaito
    Nov 27, 2015 at 15:36
4

systemd 248 (released March 2021) introduced support for the syntax -M username@ for specifying another user.

Assuming the other username is testuser and the service is foobar.service, you can now run

sudo systemctl -M testuser@ --user restart foobar.service
0

Assuming someuser uses bash as their login shell, add the following exports to ~someuser/.bashrc:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

Then, a user with root/sudo privileges can interact with someuser's systemd by wrapping the command with runuser:

sudo runuser -l someuser -c "systemctl --user restart some-template@$some-service.service"

-1

I had the same error (Failed to connect to bus: No such file or directory) when running the following command on Ubuntu 20.04:

systemctl --user mask tracker-store.service tracker-miner-fs.service tracker-miner-rss.service tracker-extract.service tracker-miner-apps.service tracker-writeback.service

The problem was because of the alias:

alias systemctl='sudo systemctl'

It substituted the systemctl with sudo systemctl and sudo caused the error.

The env vars:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

are not used because of sudo.

mkaito wrote in the comment above:

I guess sudo needs those whitelisted, because it clears the environment by default.

You must log in to answer this question.

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