[Pkg-utopia-maintainers] Bug#682375: 75dbus_dbus-launch doesn't really launch dbus

[Simon McVittie]

retitle 682375 nothing in Xsession.d can connect to the session bus
severity 682375 wishlist
thanks

On 22/07/12 10:04, YunQiang Su wrote:
> The 75dbus_dbus-launch of dbus-x11 doesn't really launch dbus but
> modified variable STARTUP and then exec $STARTUP in 99x11-common_start
>
> If another application such as fcitx (80im-config_launch) needs
> DBUS_SESSION_BUS_ADDRESS, it will fail.

This is deliberate; the alternative is worse (see #681241).

The problem is:

* activated session services are child processes of the session
  dbus-daemon
* so, activated session services inherit environment variables from
  the session dbus-daemon
* most scripts in /etc/X11/Xsession.d set environment variables
* ... so if you start dbus-daemon too early, it will miss out on
  environment variables that are set after it starts
* so activated session services don't inherit those environment
  variables either, causing them to behave incorrectly (see Launchpad
  bugs 807614 and 809900, for instance)

Starting fcitx on-demand via D-Bus service activation, rather than from
the script in Xsession.d, would solve this.

For instance, if im-fcitx Gtk and Clutter plugins and the qtim-fxitx Qt
plugin sent a D-Bus message to fcitx' well-known D-Bus name on startup,
and fcitx installed a .service file for that well-known name, then the
first use of any of those plugins would automatically launch fcitx.

> An suggestion is to run
>           eval `dbus-launch --sh-syntax --exit-with-session`
> in 75dbus_dbus-launch.

I did try that briefly, but had to revert it, because it caused bugs
itself (the two Launchpad bugs mentioned above).

I suspect the only way to solve this fully would be to give the session
dbus-daemon some sort of two-phase startup similar to systemd socket
activation: listen on the socket from a non-dbus-daemon app and allow
applications to start connecting early in Xsession.d, and set the
DBUS_SESSION_BUS_ADDRESS to that socket (but any application connecting
to it will just block). Then, later, when all the environment variables
have been set, pass the socket fd to dbus-daemon via the systemd
LISTEN_FD protocol; at that point dbus-daemon will start accept()ing
connections, and the blocked applications wake up.

I don't think that solution is feasible for wheezy, and it has its own
problems (applications attempting to use D-Bus too early will block, and
libdbus doesn't provide any way to open a D-Bus connection without
blocking on connect()).

    S