Debian – Failed to get D-Bus connection: No such file or directory. $XDG_RUNTIME_DIR not set. libpam-systemd installed

d-busdebiansystemd

I installed Yunohost on a LIME2 like I did with my Pi3 and now I have the same error as two months (see "Cannot enable user service. “Failed to get D-Bus connection: Connection refused” Support"), only this time I have libpam-systemd already installed.

admin@Gildurklaus:~ $ systemctl --user list-units
Failed to get D-Bus connection: Connection refused

Again, without the user parameter, the command runs fine.

admin@Gildurklaus:~ $ systemctl list-units

  UNIT                                                                 LOAD   ACTIVE SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount                                    loaded active waiting   Arbitrary Executable File Formats File System Automount Point
  sys-devices-platform-soc-3f201000.serial-tty-ttyAMA0-hci0-rfkill1.device loaded active plugged   /sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/rfkil
  sys-devices-platform-soc-3f201000.serial-tty-ttyAMA0-hci0.device     loaded active plugged   /sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0
  ...
  To show all installed unit files use 'systemctl list-unit-files'.
  lines 102-129/129 (END)

And again Dbus isn't running for my user, only system-wide.

admin@Gildurklaus:~ $ ps -ef | grep dbus
message+   574     1  0 05:53 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
admin     1988  1971  0 10:03 pts/0    00:00:00 grep dbus

And again, systemd does not appear to be running for this user

admin@Gildurklaus:~$ ps -ef | grep dbus
message+   574     1  0 05:53 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
admin     1988  1971  0 10:03 pts/0    00:00:00 grep dbus
admin@Gildurklaus:~$ ps -ef | grep systemd
root       183     1  0 05:53 ?        00:00:01 /lib/systemd/systemd-journald
root       187     1  0 05:53 ?        00:00:00 /lib/systemd/systemd-udevd
root       572     1  0 05:53 ?        00:00:00 /lib/systemd/systemd-logind
message+   574     1  0 05:53 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
admin     1990  1971  0 10:04 pts/0    00:00:00 grep systemd

And again $XDG_RUNTIME_DIR is missing.

admin@Gildurklaus:~ $ systemd --test
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

This time libpam-systemd is installed.

admin@Gildurklaus:~$ apt list --installed *systemd*
Listing... Done
libpam-systemd/oldstable,now 215-17+deb8u7 armhf [installed]
libsystemd0/oldstable,now 215-17+deb8u7 armhf [installed]
systemd/oldstable,now 215-17+deb8u7 armhf [installed]
systemd-shim/oldstable,now 9-1 armhf [installed,automatic]
systemd-sysv/oldstable,now 215-17+deb8u7 armhf [installed]
admin@Gildurklaus:~$ apt list --installed *dbus*   
Listing... Done
dbus/oldstable,now 1.8.22-0+deb8u1 armhf [installed,automatic]
libdbus-1-3/oldstable,now 1.8.22-0+deb8u1 armhf [installed,automatic]
libdbus-glib-1-2/oldstable,now 0.102-1 armhf [installed,automatic]
libnih-dbus1/oldstable,now 1.0.3-4.3 armhf [installed,automatic]

[update]

I've noticed a subtle difference between my Pi3 and LIME2 server.
The Pi3 starts a XDG_SESSION_ID session, while the LIME2 server doesn't.

Pi3

admin@Yroklaus:~ $ sudo systemctl status systemd-logind.service
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: active (running) since Sat 2018-03-24 15:43:32 UTC; 1h 27min ago
     Docs: man:systemd-logind.service(8)
           man:logind.conf(5)
           http://www.freedesktop.org/wiki/Software/systemd/logind
           http://www.freedesktop.org/wiki/Software/systemd/multiseat
 Main PID: 508 (systemd-logind)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-logind.service
           └─508 /lib/systemd/systemd-logind

Mar 24 15:43:32 Yroklaus systemd[1]: Starting Login Service...
Mar 24 15:43:32 Yroklaus systemd-logind[508]: New seat seat0.
Mar 24 15:43:32 Yroklaus systemd[1]: Started Login Service.
Mar 24 15:43:32 Yroklaus systemd-logind[508]: Couldn't add lingering user folatt: No such file or directory
Mar 24 15:43:32 Yroklaus systemd-logind[508]: User enumeration failed: No such file or directory
Mar 24 16:47:01 Yroklaus systemd-logind[508]: New session c1 of user admin.

LIME2 

admin@Gildurklaus:~$ sudo systemctl status systemd-logind.service
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: active (running) since Sat 2018-03-24 16:43:45 CET; 1h 27min ago
     Docs: man:systemd-logind.service(8)
           man:logind.conf(5)
           http://www.freedesktop.org/wiki/Software/systemd/logind
           http://www.freedesktop.org/wiki/Software/systemd/multiseat
 Main PID: 571 (systemd-logind)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-logind.service
           └─571 /lib/systemd/systemd-logind

Mar 24 16:43:45 Gildurklaus systemd-logind[571]: New seat seat0.
Mar 24 16:43:45 Gildurklaus systemd[1]: Started Login Service.

Best Answer

And again Dbus is running.

No, it clearly is not. And it was not the last time, either.

Your process listing shows only the system-wide Desktop Bus broker. Note the --system in the command arguments and the fact that the process is not running as you.

When you run systemctl with the --user option it talks to your per-user instance of systemd via your per-user Desktop Bus broker.

Neither is in fact running.

You'll likely find that starting up the per-user instance of systemd will start up the per-user Desktop Broker as well. The former manages the latter, and the dbus.socket unit (from /usr/lib/systemd/user/dbus.socket) is likely already enabled for your per-user service manager. (Observe that it is the socket unit that has to be enabled, not the service unit.)

So it's actually the same answer as before, even though it wasn't explicit in the last Q&A: Make sure that your per-user instance of systemd is running, and make sure that that starts up your per-user Desktop Bus broker. You can run the steps that pam_systemd runs by hand, to check that they themselves work in the first place. Then check that pam_systemd is configured to actually be called as part of your login procedure.

And bear in mind that su is not a login mechanism. It works within an existing interactive login session. If you are not logging in as the account in question, the systemd hooks will not be activating the per-user instance of systemd for that account.

Further reading

Related Question