On 03/06/14 10:03, Martin Pitt wrote: > Many display managers > (gdm, lightdm, etc.) already start a session D-BUS, so starting > another one in Xsession.d/ seems redundant. That hasn't normally led > to bugs, but we just encountered a situation (due to wrong startup > ordering, i. e. a bug) where different processes were using different > D-BUSes. I came with conceptually the same patch as Panayiotis. While > this is not by itself a full bug fix, it helps to better debug these > problems and also avoids duplicate bus startup. It's also really cheap > to do.
If both places that try to run a session dbus-daemon use 'dbus-launch --exit-with-session' under a running X server, then they will both use the same X11 mechanisms; the first one will start a dbus-daemon, and the second will use the selection/window to detect and use that same dbus-daemon. So that should already work gracefully? However, as I already said to Panayiotis, the problem with this is that activated services are children of the dbus-daemon, and people frequently expect to be able to set environment variables (in Xsession.d or otherwise) and have the activated services inherit them (see <https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/807614>, <https://bugs.launchpad.net/unity/+bug/809900>, <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682375>). gnome-session works around this by using the UpdateActivationEnvironment() method to push environment variables into dbus-daemon's environment later, but there is still going to be an unavoidable window between startup and the call to UpdateActivationEnvironment() in which any activated services will be missing some environment variables. If you want to start a dbus-daemon at the beginning of Xsession.d (or even before Xsession.d), to get the intended behaviour of environment variables in Xsession.d it would be necessary to add a new program to the end of Xsession.d that takes the environment and pushes it into the dbus-daemon with UpdateActivationEnvironment(). This would have to be C code using libdbus (or possibly GDBus), because dictionaries are not dbus-send-friendly. It would also have to be careful to skip any environment variables whose values are not UTF-8. I'd be happy to review a patch upstream that did this; upstream it would be for dbus 1.9.x, but I'd consider backporting it into the 1.8.x series in Debian. Other possibilities include: * systemd user sessions using systemd --user for activation (but Lennart seems to be intent on requiring kdbus for those) * two-phase initialization analogous to systemd socket activation, which starts a listening socket at the beginning of Xsession.d (or in *dm), then attaches a dbus-daemon to it at the end * deprecating Xsession.d (which is always going to have awkward corner cases like this, AFAICS, but I'm not stubborn and thick-skinned enough to be the one to tell @1990sLinuxUser that it isn't perfect) S -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
