[Pkg-utopia-maintainers] Bug#815503: dbus-x11: Several session buses if scripts in Xsession.d use D-Bus

[Simon McVittie]

Control: retitle 815503 dbus-x11: Several session buses if scripts in Xsession.d use D-Bus
Control: tags 815503 jessie

On Sun, 21 Feb 2016 at 23:50:09 +0100, Samuel Thibault wrote:
> We have been noticing several dbus-daemon --session being started during
> a user session, which creates a mess, notably with accessibility
> engines.

The traditional answer, and the answer applicable to jessie, has been
"you can't do that, it is incorrect to run dbus-launch or use dbus-daemon
in Xsession.d".

The problem is that whenever dbus-launch happens to be started, the
environment variables that were in its environment at that time are what
ends up in the dbus-daemon's environment. This means that if anything
in Xsession.d tries to run after dbus-launch and set an environment
variable, bus-activated services will not see that environment variable. A
significant number of scripts in /etc/X11/Xsession.d/ exist only to set
environment variables, particularly in older Debian releases, so this
works poorly.

Since dbus 1.10 (in stretch), we have mitigated this differently, by
running dbus-launch from 75dbus_dbus-launch as you suggest, but then
running another script (95dbus_update-activation-env) very late in
Xsession.d, which uploads most of its new environment into the existing
dbus-daemon (and into the equivalent launch environment in systemd --user,
if running). This is a significant structural change which requires
an additional upstream executable, so I would be somewhat reluctant
to backport it into an existing stable release, and I don't think the
release team are very likely to accept it.

That is also still not a full solution to the problem that setting
environment variables in /etc/X11/Xsession.d conflicts with starting
long-running daemons from /etc/X11/Xsession.d: anything started via D-Bus
activation or as a systemd user service between 75dbus_dbus-launch and
95dbus_update-activation-env will not pick up an environment variable set
by (for example) 90atk-adaptor. However, it's the best I could think of.

I think the long-term solution to this is for normal use of the platform
to rely less on environment variables and script hooks, and more on files
and sockets with well-known names in $HOME or in the $XDG_RUNTIME_DIR
set up by systemd-logind or equivalent (such as $XDG_RUNTIME_DIR/bus
with the dbus-user-session package) and on-demand auto-activation
(D-Bus activation, systemd socket activation, .desktop files in
/etc/xdg/autostart and similar mechanisms). It's fine to have environment
variables as an override for special purposes, but just using the
system normally shouldn't need as many of them as it does. For example,
the dbus-user-session package changes $DBUS_SESSION_BUS_ADDRESS from
"essential for normal use" to "only needed for backwards compatibility",
and recent gnupg-agent versions have greatly reduced the need for
$GPG_AGENT_INFO by using a well-known socket path.

On non-systemd systems, Ubuntu used to have a standalone implementation
of $XDG_RUNTIME_DIR as a PAM module (libpam-xdg-support). However, Ubuntu
no longer uses it and the last commit was in 2012, so if people want this
structure without systemd, they will probably have to become its upstream
maintainers. I suspect that we're more likely to end up with systemd
systems working well, and non-systemd systems continuing to stumble
along with best-effort support that works if nobody sneezes too hard.

    S