FS#46363 - [dbus] can no longer create a bus connection: connection refused

Attached to Project: Arch Linux
Opened by John (graysky) - Sunday, 20 September 2015, 21:22 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 April 2016, 14:21 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

I have a minimal headless server (no Xorg) and only connect via ssh. Upon updating to and dbus-1.10.0-3 and libdbus-1.10.0-2, I can no longer use user sessions.

Example:
% systemd-run --user /bin/sleep 60
Failed to create bus connection: Connection refused

If I downgrade to the previous versions (and reboot) everything works as expected:
% systemd-run --user /bin/sleep 60
Running as unit run-1117.service.

The wiki shows a three step process to workaround this, but it was authored well before these packages so I am hesitant to try it.

Additional info:
* package version(s): dbus-1.10.0-3 and libdbus-1.10.0-2
* config and/or log files etc: none


Steps to reproduce:
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 07 April 2016, 14:21 GMT
Reason for closing:  Fixed
Comment by Dave Reisner (falconindy) - Sunday, 20 September 2015, 22:37 GMT
Works for me. Have you overriden/supplemented the user dbus.service or dbus.socket? Overridden environment? What's the value of DBUS_SESSION_BUS_ADDRESS from the ssh session?
Comment by Jan Alexander Steffens (heftig) - Sunday, 20 September 2015, 22:54 GMT
Did you disable UsePAM in sshd_config?
Comment by John (graysky) - Monday, 21 September 2015, 00:06 GMT
@Dave - This is a virgin install to a new partition. I haven't created dbus.service or dbus.socket. Whatever the packages provided is on the filesystem. If I execute `systemd-run --user /bin/sleep 60` using the older packages, and then echo $DBUS_SESSION_BUS_ADDRESS is comes back null, but the command runs just fine. When I update to the current versions, reboot and execute it again, it does not run, and again, $DBUS_SESSION_BUS_ADDRESS is null.

@heftig - No, it is enabled in /etc/ssh/sshd_config.
Comment by John (graysky) - Monday, 21 September 2015, 06:22 GMT
In an attempt to troubleshoot, I began disabling other services/rebooting and found that having /etc/systemd/system/vncserver@:1.service enabled was to blame. When I disable it from starting automatically by systemd and simply start it manually from an ssh session, everything works [user sessions work and $DBUS_SESSION_BUS_ADDRESS is assigned] as expected on a reboot; if I re-enable it and reboot, the problem comes back. What in the service would be causing this problem (attached) and is it a bug with the latest versions of the packages?
   vncserver@:1.service (0.4 KiB)
Comment by Jan Alexander Steffens (heftig) - Monday, 21 September 2015, 06:41 GMT
The problem doesn't seem to be the session created; I tried with the service below and a subsequent login via ssh had a proper DBUS_SESSION_BUS_ADDRESS.

[Unit]
Description=Foobar

[Service]
User=guest
PAMName=login
ExecStart=/usr/bin/sleep 1d
Comment by John (graysky) - Monday, 21 September 2015, 06:50 GMT
Can you recreate the problem using the service I posted on a box without graphical login which might be important as login managers may do the magic.

1) Disable your display manager so you boot to a tty on the next boot
2) Install tigervnc
3) Configure the first time vncserver for your user (basically just setup a password)
4) Edit the attached service for your user and place it in /etc/systemd/system
5) Enable it so systemd starts it automatically and reboot
6) Connect via ssh an try to run `systemd-run --user /bin/sleep 60`
Comment by Jan Alexander Steffens (heftig) - Monday, 21 September 2015, 06:53 GMT
Hm, can you try adding After=systemd-user-sessions.service to your service?
Comment by John (graysky) - Monday, 21 September 2015, 06:57 GMT
Yes, I changed the After= line in the attached to read: After=syslog.target network.target systemd-user-sessions.service

I enabled it and rebooted and the "bug" continues.
Comment by Jan Alexander Steffens (heftig) - Monday, 21 September 2015, 07:09 GMT
How about if you now use `loginctl enable-linger facade`?

If that still doesn't work, one possible remedy here could be turning vncserver@.service into a user service /etc/systemd/user/vncserver@.service:

[Unit]
Description=Remote desktop service (VNC for display %i)

[Service]
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=-/usr/bin/vncserver -kill %i
ExecStart=/usr/bin/vncserver -desktop sandbox -geometry 2000x1200 -AlwaysShared -localhost -dpi 100 -fg %i
ExecStop=/usr/bin/vncserver -kill %i

[Install]
WantedBy=default.target

Enable (as facade: `systemctl --user enable vncserver@:1`), disable the system service (`systemctl disable vncserver@:1`) and reboot. Lingering for facade is still needed as well, otherwise the server will not be started at boot, but when you log in.
Comment by Oleksandr (cross) - Saturday, 26 September 2015, 15:13 GMT
Think my issue have the same source:

Cannot start gnome-shell and nautilus with latest packages.

dbus-daemon message:
[system] Activation via systemd failed for unit 'dbus-org.freedesktop.NetworkManager.service': Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory.

gnome-session messages:
(gnome-settings-daemon:814): rfkill-plugin-WARNING **: Failed to acquire NetworkManager proxy: Error calling StartServiceByName for org.freedesktop.NetworkManager: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory.
Gjs-Message: JS LOG: Failed to launch ibus-daemon: Failed to execute child process "ibus-daemon" (No such file or directory)
Gjs-Message: JS LOG: No permission to trigger offline updates: Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.packagekit.trigger-offline-update is not registered

[somewhere in the middle of the above messages] colord message:
/usr/lib/colord/colord-sane: error while loading shared libraries: libsane.so.1: cannot open shared object file: No such file or directory

After rollback to 'dbus-1.10.0-2-x86_64.pkg.tar.xz systemd-225-1-x86_64.pkg.tar.xz libdbus-1.10.0-2-x86_64.pkg.tar.xz' everything goes OK.

Loading...