I think the gvfs check mentioned on the systemd bug is too conservative, now that GDBus (like libdbus and sd-bus) knows to try XDG_RUNTIME_DIR/bus by default.

Since that gvfs bug was closed in 2009, dbus has also changed: since 1.4.8 (2011) we won't attempt X11 autolaunch unless we have an X11 DISPLAY, so it is neither necessary nor desirable for random services to try to avoid autolaunch. So I'm tempted to ask the gvfs developers to remove that check.

However, I'd be fine with adding something like this if systemd people think it's the best solution.

> I'm not sure using EXPANDED_BINDIR to find systemctl is the best approach.

Neither am I: there's no guarantee that D-Bus and systemd share a ${prefix}. I think I'd rather use

AC_PATH_PROG([SYSTEMCTL], [systemctl], [/usr/bin/systemctl])

which will be right 90% of the time, and can easily be overridden with something like

./configure ... SYSTEMCTL=/bin/systemctl

if the OS has split-/usr or another non-typical layout, *and* is building in a minimal chroot with no systemctl executable.

(In reply to Simon McVittie from comment #1)
> I think the gvfs check mentioned on the systemd bug is too conservative, now
> that GDBus (like libdbus and sd-bus) knows to try XDG_RUNTIME_DIR/bus by
> default.
> 
> Since that gvfs bug was closed in 2009, dbus has also changed: since 1.4.8
> (2011) we won't attempt X11 autolaunch unless we have an X11 DISPLAY, so it
> is neither necessary nor desirable for random services to try to avoid
> autolaunch. So I'm tempted to ask the gvfs developers to remove that check.
> 
> However, I'd be fine with adding something like this if systemd people think
> it's the best solution.

I'd very much prefer if people fixed the software in question. If a program provides a user-unit (like gvfs does), it better not depend on the session bus (read: DBUS_SESSION_BUS_ADDRESS). This doesn't make sense. A user unit is not running in a session. I'd like to hear why gvfs suddenly does this? Easiest fix would be to not install those systemd user units of gvfs.

However, I could imagine a setup where an application uses the user-bus (or none), and as such provides a user-unit. But it might be linked to a library that under the hood tries connecting to the *session*-bus. Not that I like supporting such programming style, but strict backwards-compat might as such required DBUS_SESSION_BUS_ADDRESS to be set.

Long story short: I'm fine with both. Adding the snippet to dbus.socket, or talking with respective upstream to fix their dbus-safety-checks.

(In reply to David Herrmann from comment #2)
> If a program
> provides a user-unit (like gvfs does), it better not depend on the session
> bus (read: DBUS_SESSION_BUS_ADDRESS).

It provides user units that are not automatically started (they have no [Install]), but that can be started by D-Bus activation (via SystemdService in the D-Bus .service file), *if* dbus-daemon --session was run with --systemd-activation. That only happens if you are using dbus-daemon --session in "user bus" mode (dbus.socket), at which point dbus-daemon --session *is* a user bus.

> I'd like to hear why gvfs suddenly does this?

So that we can have gvfs services run in their own cgroups (rather than as children of dbus.service) without waiting for kdbus, which has been "just around the corner" for quite some time now. In gvfs' case, I contributed those user units.

> Long story short: I'm fine with both. Adding the snippet to dbus.socket, or
> talking with respective upstream to fix their dbus-safety-checks.

The conservative route would seem to be "do both" then.

Created attachment 119145 [details] [review]
user dbus.socket: Set DBUS_SESSION_BUS_ADDRESS

From: "Jan Alexander Steffens (heftig)" <jan.steffens@gmail.com>

As discussed in https://github.com/systemd/systemd/issues/1600

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92612
[smcv: use AC_PATH_PROG to find systemctl; ignore systemctl failure]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

---

David, could you review this version please?

I think this is an isolated enough change that we could do it in 1.10.x.

Original bug reports:

https://bugs.archlinux.org/task/46721
https://bugzilla.gnome.org/show_bug.cgi?id=756420

Looks good to me:

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks a lot!

Fixed in 1.10.2

This appears to cause problems with X2Go and VNC sessions, see https://bugzilla.redhat.com/show_bug.cgi?id=1350004 and https://github.com/TigerVNC/tigervnc/commit/c071e493a093d7ee9a568729dd2e151f5cd3d749 

Any thoughts on this?  Should everything that starts a DE need to unset DBUS_SESSION_BUS_ADDRESS first?

(In reply to Orion Poplawski from comment #8)
> This appears to cause problems with X2Go and VNC sessions, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1350004 and
> https://github.com/TigerVNC/tigervnc/commit/
> c071e493a093d7ee9a568729dd2e151f5cd3d749 
> 
> Any thoughts on this?  Should everything that starts a DE need to unset
> DBUS_SESSION_BUS_ADDRESS first?

(Background on user-sessions vs. login-sessions, including the terms I'm using: <https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html>.)

If a distribution aims to support multiple simultaneous D-Bus session buses for one uid, then they should not use the user bus, and instead leave D-Bus configured the way it was in 2010. I don't really recommend this, but if it's what you want, an open source platform means you have the freedom to make decisions I don't agree with.

We can't have it both ways: either the session bus is per login-session, or it is per user-session. This is a decision for operating system designers. The changes we have made in D-Bus make it possible for operating system designers to choose either way: they do not force the decision one way or the other. As an OS designer, I recommend the per-user-session bus, but as a D-Bus maintainer, I'm continuing to support both.

In Debian, you can opt-in to the per-user-session bus by installing the dbus-user-session package; if you do not install that package, you get the 2010-era per-login-session bus. If distributions like Fedora and Arch have chosen not to provide a way to switch between the two models, that's up to them; it's their choice where they want to be on a scale between maximum flexibility and maximum predictability.

If you start new buses in a one-per-login-session mode on an otherwise bus-per-user-session OS distribution, you are likely to get into a "split brain" situation where parts of the session disagree on where to find D-Bus services. For example, "systemd --user" is inherently one-per-user-session, so any service started as a child of systemd --user is going to use the per-user-session bus. I would strongly recommend against this, but if you or your preferred OS distribution designer have understood the problems and want to do this anyway, that's your call.

(In an OS distribution configured to have a bus per login-session, the services started by systemd --user just don't have access to a D-Bus session bus at all - significantly reduced functionality when compared with the per-user-session model, but at least it's internally consistent.)

If you want to start a session or pseudo-session with its own bus, I would recommend wrapping that session's main executable in the dbus-run-session(1) tool, or in "dbus-launch --exit-with-session" if the session is known to have its own dedicated X11 display. Please prefer to do one of those instead of unsetting DBUS_SESSION_BUS_ADDRESS, which means you are relying on X11 autolaunching to get a session bus per X11 display. X11 autolaunching is inefficient and has historically not been entirely reliable: it brings more complexity into the critical path than if you used dbus-run-session or "dbus-launch --exit-with-session".

If you run dbus-launch without the --exit-with-session option, then whatever you are doing is probably incorrect. We can't change its behaviour without breaking compatibility, but that behaviour is usually wrong and I would recommend against it.