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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
