Cannot use `systemctl --user` due to "Failed to get D-bus connection: permission denied"

Question

I'm trying to set up user-level services, using this answer to a similar question. I have create the required files and rebooted.

I'm making progress because I now get "Failed to get D-bus connection: permission denied" when it was "Failed to get D-bus connection: connection refused", but I'm stumped because I don't know what object it is trying to access (file? socket?) and so cannot even check current permissions. Any ideas?

So far I have added:

loginctl enable-linger userservice

/usr/lib/systemd/user/dbus.service (-rw-r--r-- root root)

[Unit]
Description=D-Bus User Message Bus
Requires=dbus.socket

[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

[Install]
Also=dbus.socket

/usr/lib/systemd/user/dbus.socket (-rw-r--r-- root root)

[Unit]
Description=D-Bus User Message Bus Socket

[Socket]
ListenStream=%t/bus
ExecStartPost=-/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus

[Install]
WantedBy=sockets.target
Also=dbus.service

/home/userservice/.config/systemd/user/userservice.service

[Unit]
Description=Test user-level service

[Service]
Type=dbus
BusName=com.wtf.service
ExecStart=/home/userservice/userservice.py
Restart=on-failure

[Install]
WantedBy=default.target

Not added any links elsewhere...

To make it fail:

systemctl --user status

Edit 2018-10-25:

Added export XDG_RUNTIME_DIR=/run/user/$(id -u) to .bashrc. The variable is set and now I get: Failed to get D-us connection: no such file or directory. Strangely, neither man systemctl nor systemctl --help mention the --user option, while both mention --system and specify that this is the default (so what are the other options).

Using RHEL 7.4 (with systemd 219 as reported by systemctl --version) with SELinux.

Answer 1

I've noticed the tableau server uses --user systemd services - they even have a note about this in their docs: https://help.tableau.com/current/server-linux/en-us/systemd_user_service_error.htm

The systemd user service is not used as commonly as the normal systemd process manager. Red Hat disabled the systemd user service in RHEL 7 (and thereby all distros that come from RHEL, like CentOS, Oracle Linux 7, Amazon Linux 2). However, RedHat has assured Tableau that running the systemd user service is supported as long as the service is re-enabled.

How they do it (example is with a userid 29575)

# cat /etc/systemd/system/[email protected]
[Unit]
Description=User Manager for UID %i
After=systemd-user-sessions.service
# These are present in the RHEL8 version of this file except that the unit is Requires, not Wants.
# It's listed as Wants here so that if this file is used in a RHEL7 settings, it will not fail.
# If a user upgrades from RHEL7 to RHEL8, this unit file will continue to work until it's
# deleted the next time they upgrade Tableau Server itself.
After=user-runtime-dir@%i.service
Wants=user-runtime-dir@%i.service

[Service]
LimitNOFILE=infinity
LimitNPROC=infinity
User=%i
PAMName=systemd-user
Type=notify
# PermissionsStartOnly is deprecated and will be removed in future versions of systemd
# This is required for all systemd versions prior to version 231
PermissionsStartOnly=true
ExecStartPre=/bin/loginctl enable-linger %i
ExecStart=-/lib/systemd/systemd --user
Slice=user-%i.slice
KillMode=mixed
Delegate=yes
TasksMax=infinity
Restart=always
RestartSec=15

[Install]
WantedBy=default.target

After you create that file:

systemctl daemon-reload
systemctl enable [email protected]
systemctl start [email protected]

And you'll need to set XDG_RUNTIME_DIR in env of that user via bashrc or similar:

[ -z "${XDG_RUNTIME_DIR}" ] && export XDG_RUNTIME_DIR=/run/user/$(id -ru)

I've tested in on a recent RHEL 7.8 and it works as expected, I can run "systemctl --user status" as my user after doing this.

Answer 2

So there's a long standing issue where the XDG_RUNTIME_DIR environment variable doesn't get set properly, or at all, when users log in, and therefore can't access the user D-Bus. This happens when the user logs in via some other method than the local graphical console.

You can work around this by adding to the user's $HOME/.bashrc:

export XDG_RUNTIME_DIR=/run/user/$(id -u)

Then log out and back in.

Answer 3

You should be aware of how the PAM works.

If you login in the system using either of

1. graphical session
2. login on terminal (username and password)
3. ssh

then the PAM machinery will call pam_systemd, and this will setup all needed hooks to use systemctl; if you switch user using sudo or su, this will not happen.

This is deliberate , see https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

What's weird is that actually /etc/pam.d/su includes /etc/pam.d/common-session that contains an invocation of pam_systemd but this fails, indeed the /var/log/auth.log says:

pam_systemd(su:session): Cannot create session: Already running in a session

Currently, a good way is to use ssh to connect to the same machine but as another user, something like ssh user@localhost.

Answer 4

systemd 248 (relased March 2021) introduced the syntax

systemctl --user -M username@ status

(that command needs to be run as root)

For example

[myuser@laptop ~]$ sudo systemctl --user -M testuser@ status
● testuser@
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2022-11-03 22:59:10 CET; 164ms ago
   CGroup: /user.slice/user-1492.slice/[email protected]
           ├─init.scope
           │ ├─ 21922 /usr/lib/systemd/systemd --user
           │ └─ 21929 "(sd-pam)"
           └─session.slice
             └─dbus-broker.service
               ├─ 21950 /usr/bin/dbus-broker-launch --scope user
               └─ 21951 dbus-broker --log 4 --controller 9 --machine-id fa369ab69fcf4e54ad8a274517ea5096 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000

Alternatively you could also open a new interactive login session

[myuser@laptop ~]$ sudo machinectl shell testuser@
Connected to the local host. Press ^] three times within 1s to exit session.
[testuser@laptop ~]$ systemctl --user status
● laptop
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2022-11-03 22:56:50 CET; 57s ago
   CGroup: /user.slice/user-1492.slice/[email protected]
           └─init.scope
             ├─ 21799 /usr/lib/systemd/systemd --user
             └─ 21806 "(sd-pam)"

"sudo -u username -i" does not create a systemd login session

su is "not a tool for opening a completely new login session" according to https://github.com/systemd/systemd/issues/7451#issuecomment-346787237 (I assume sudo is related to su. Just running sudo to become another user will no start that user's systemd daemon)

I tried out a few examples on a Fedora 36 with systemd 250:

Example "sudo -u username -i"

[myuser@laptop ~]$ sudo useradd test1
[myuser@laptop ~]$ sudo -u test1 -i
[test1@laptop ~]$ pgrep -u $USER -l
25217 bash
[test1@laptop ~]$ env | grep XDG
XDG_DATA_DIRS=/home/test1/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
[test1@laptop ~]$ 

Example "sudo machinectl shell username@"

[myuser@laptop ~]$ sudo useradd test2
[myuser@laptop ~]$ sudo machinectl shell test2@
Connected to the local host. Press ^] three times within 1s to exit session.
[test2@laptop ~]$ pgrep -u $USER -l
25086 bash
25091 systemd
25100 (sd-pam)
25115 (sd-pam)
[test2@laptop ~]$ env | grep XDG
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_SESSION_ID=51
XDG_RUNTIME_DIR=/run/user/1494
XDG_DATA_DIRS=/home/test2/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
[test2@laptop ~]$ ls -l $XDG_RUNTIME_DIR/bus
srw-rw-rw-. 1 test2 test2 0 Nov  4 08:42 /run/user/1494/bus
[test2@laptop ~]$ 

Reference:

Relevant lines from the systemd 248 release notes: https://github.com/systemd/systemd/blob/6c83054c0133eb53245e479d71589dceff76cf74/NEWS#L2796-L2800