Ubuntu
systemd package

systemd --user does not work: 'Failed to connect to bus'

Asked by Andreas Florath

Hello!

I want to start a service at boot time as a user.

    # loginctl enable-linger username

works. systemd --user process is started - even after a reboot.

But all calls using 'systemctl --user' fail; example:

    $ systemctl --user status
    Failed to connect to bus: No such file or directory

    $ systemctl --user enable xyz
    Failed to connect to bus: No such file or directory

When running systemctl command (as normal user or root) using the system-systemd instance everything works fine. The root-user is able to use the system and user systemd instances - no problems here.

I had a closer look what exactly fails:
As a 'normal' user it only tries to connect to
    /sys/fs/kdbus/1001-user/bus
which is not available - and then stops.
Same under root, check the same kdbus (of course with 0-user), also fails, but then
looks in addition for the /run/user/0/systemd/private socket.

I tried to start an own dbus for the user, but I failed:
all solutions I tried / found need a working systemd-user installation.

Please note that this is Ubuntu Xenial (packages from last night) only minimal (server) installation - without any GUI / X.

What am I missing here? Any hints or comments are welcome!
Need more information? Just give me a hint what is needed.

Kind regards

Andre

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu systemd Edit question
Assignee:
No assignee Edit question
Solved by:
Andreas Florath
Solved:
Last query:
Last reply:
Revision history for this message
Thomas ten Cate (ttencate) said : 		#1

Arch user here, but I had exactly the same symptoms with systemctl, looking for kdbus only, even though I'm using regular dbus. It turns out this is because XDG_RUNTIME_DIR is not set. Try:
export XDG_RUNTIME_DIR=/run/user/`id -u`
As to *why* the variable is not set, I'm not sure. I gather it's supposed to be set by pam_systemd.

Revision history for this message
Andreas Florath (florath) said : 		#2

Thank you very much!

As a workaround I'll set the environment variable in the profile of the user.

[Note for the files: the problem is not solved - there might be a 'real' bug in some packet - but there is an easy to use work-around.]

Revision history for this message
Arne Beer (i-arne) said : 		#3

Actually this issue is not resolved yet!

I'm using arch as well and I'm still getting this error on my headless server.
There is definitely a bug in there.

@florath:

Could you reopen the ticket. We need to get a some attention for this bug!

Revision history for this message
Arne Beer (i-arne) said : 		#4

I found another hint:

If you try to execute dbus-monitor, I receive:
Failed to open connection to session bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead

env output:

USER=root
LOGNAME=root
HOME=/root
PATH=/root/.scripts/:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
MAIL=/var/mail/root
SHELL=/usr/bin/zsh
TERM=xterm-256color
SHLVL=1
PWD=/root
OLDPWD=/root
EDITOR=vim
ANSIBLE_NOCOWS=1
BROWSER=chromium
XDG_DESKTOP_DIR=/root/
NVIM_TUI_ENABLE_TRUE_COLOR=1
NVIM_TUI_ENABLE_CURSOR_SHAPE=1
LANG=en_US.UTF-8

Revision history for this message
Andrew Lamarra (amlamarra) said : 		#5

I'm having this same issue on my Raspberry Pi running Raspbian. systemctl --user works fine on the default pi account, but not on the second user account I created. The XDG_RUNTIME_DIR variable is correctly set.

Revision history for this message
Andrew Lamarra (amlamarra) said : 		#6

And then a reboot fixed it...

Revision history for this message
kimifish (kimiside) said : 		#7

Experiencing this in half the reboots on Ubuntu 16.04.

This works for me:

export XDG_RUNTIME_DIR=/run/user/`id -u`
sudo systemctl restart systemd-logind.service

but it would be much more useful to find the source of problem.

Revision history for this message
Thomas ten Cate (ttencate) said : 		#8

For me, the problem turned out to be a failing userland systemd service. I had set a long running process to `Type=oneshot`, which caused the userland systemd to take a long time to report "started" back to the system systemd. The system systemd subsequently decided that it took too long to start (1 minute? 1.5 minutes?) and killed the user systemd. This can be checked by looking at the status of the _system_ service `user@1000.service` (where 1000 is your user id).