-
The two known use-cases for autolaunching are: * X-forwarding: "ssh -Y myhost myapp" resulting in a session bus on myhost but an X server on the original host * Legacy desktop environments on OSs without D-Bus integration: e.g. running a single GNOME or KDE app under fvwm or something, without a session dbus-daemon being started by either systemd, gnome-session, or OS integration scripts analogous to Debian's /etc/X11/Xsession.d/75dbus_dbus-launch In either case, an X11 DISPLAY is also needed. "dbus-launch --autolaunch" doesn't do anything useful when unable to connect to an X11 display; this has been the case since the feature was added in 2006, and is useful to avoid "split brain" situations in which two processes that ought to be part of the same session end up on separate session buses. Since dbus commit 407c111 in 2011, libdbus hasn't even attempted to run "dbus-launch --autolaunch" unless getenv("DISPLAY") returns non-null in the parent: this avoids doing a relatively complicated fork-and-exec that is clearly not going to lead to success. This commit gives GDBus the same policy. This change was originally made to work around a race condition in subprocess spawning (Debian bug #737380, GNOME bug #711090) but it seems valid in its own right. In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should be considered to be an X11 feature, and any future D-Bus enhancements (e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain a session bus address by other means - either a session manager such as "systemd --user", gnome-session or Upstart, or a wrapper for the user session like dbus-run-session(1). Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506 Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
0f2e4fd0