In a recent Lubuntu 22.04 install, when running systemctl --user with user 1000 I get:

❯ systemctl status --user
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
❯ eval $(dbus-launch --sh-syntax)
❯ systemctl status --user
Failed to read server status: Process org.freedesktop.systemd1 exited with status 1

However, when using another user (1001), or the same user, via su $user, systemctl status --user works just fine.


  • When the user 1001 has an active tty session (via su, ls /run/user shows 1001 and systemctl status user-1001.slice shows it active.
  • journalctl -u user-1000.slice shows no errors.
  • The problem is the same for newly created users.
  • Is user 1000 is 'delta', executing su delta (from delta's ssh session), and then systemclt --user, all works. Somehow, su creates the needed environment, but not ssh.

What else can I do to debug the problem? Can I restore systemd status config to a fresh state?, or copy something from 1002 to 1001?

  • What's the output of echo $XDG_RUNTIME_DIR $UID $DBUS_SESSION_BUS_ADDRESS? It sounds like your sshd is not setting up your environment. Try machinectl login .host (from the systemd-container package)
    – Stewart
    Feb 6, 2023 at 13:39

2 Answers 2


Borrowing from:

Failed to get D-Bus connection: Connection refused

You'll get the Failed to connect to bus when $XDG_RUNTIME_DIR is not equal to $UID. This can happen if you are logged in as one user, then su to another user.

I suspect you are logged in as user 1000. Then you are su'd to user 1001. You are trying to user the systemctl --user bus as user 1001, but that doesn't work until you did the su 1000 ... which makes $UID equal to $XDG_RUNTIME_DIR again.

There are probably other ways you can get into this situation.

The solution is to avoid using su at all. 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,

Instead, ensure you are logged in with a full session. Some ways to do this:

  • "This can happen if you are logged in as one user, then su to another use" --> not my case: I ssh using delta, exec system status --user, it fails; then I run su delta (from delta's ssh session), and the same command works.
    – Sebastian
    Feb 6, 2023 at 13:18
  • in my man pages for machinectl login it says "If an argument is supplied, it refers to the container machine to connect to" - so I'm not sure machinectl login delta is correct. I think instead we want sudo machinectl shell [email protected]. However I'm also very new to this so I could be misunderstanding
    – aaaaaa
    Jan 22 at 16:00

UsePAM yes was missing from my sshd config.

You must log in to answer this question.

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