dbus-run-session output.

[Simon McVittie]

On Fri, 07 Apr 2017 at 21:19:37 +0930, Simon Lees wrote:
> On 04/07/2017 08:35 PM, Simon McVittie wrote:
> > I'm curious why your users don't already have a D-Bus session bus?
> > In other distributions such as Debian and Fedora, the session bus is
> > automatically started by general OS integration infrastructure:
> > 
> I am equally curious, I think in this case the user is doing something
> like using i3m and I have no idea how its been launched, gnome, kde and
> enlightenment all launch with a systemd user session and seem to be fine.

The way this works in Debian is that all X11 sessions - desktop
environment or not, and systemd or not - get a dbus-daemon by default
(assuming that either the dbus-user-session or dbus-x11 package is
installed, which in practice it is). In the dbus-x11 case, it is started
by distro infrastructure like /etc/X11/Xsession.d, which is Debian's
equivalent of Red Hat and Arch Linux /etc/X11/xinit/xinitrc.d;
you probably have an equivalent in openSUSE, but I don't know what yours
is called. We don't rely on something like gnome-session for this.

Desktop environments typically also run dbus-launch if they don't find
a D-Bus session bus already available (I know GNOME and its derivatives
all do, in gnome-session or one of its various forks).

If the distro infrastructure didn't start a dbus-daemon, and the desktop
environment launcher (gnome-session or equivalent) *also* didn't start
a dbus-daemon, then the last resort is that D-Bus client library
implementations will "autolaunch" one dbus-daemon per (X11 display, uid)
pair by running dbus-launch(1) with special options. This is less good
than the distro infrastructure or the desktop environment doing it, but
it's still better than wrapping arbitrary programs in dbus-run-session.

On Debian, dbus-launch(1) is in the dbus-x11 package; again, presumably
you have an equivalent but I don't know what it is.

> > [The session bus] seems like something that OS integrators should be
> > providing, rather
> > than something individual users should be wrapping around their emacs
> > processes?
> >
> Yeah I agree, atleast in this case its a emacs launch script shipped by
> the distro doing the wrapping so the users aren't seeing it on there own.

Wrapping arbitrary processes in dbus-run-session seems like a bad idea.
A process that is run like that is its own tiny session as far as
D-Bus is concerned: that's fine if it's something like a regression test
that expects to be in its own little world, but at least unexpected
and at worst actively harmful otherwise.

The messages you quoted were about GConf, a configuration storage
system. I'm fairly sure GConf uses its name on the session bus as
a mutex to arrange for a single writer. If the same user has
multiple instances of GConf running, then they are going to have
broken last-write-wins semantics. This is actively harmful, and could
cause configuration changes by the user to be discarded; please don't.

If what you want is for a last-resort session bus to magically appear
when all other options have failed, then autolaunching is the answer.
This was in D-Bus from the beginning, as a stopgap solution to the
chicken-and-egg situation where programs otherwise couldn't start to
rely on D-Bus until they could rely on distros and/or desktop environments
providing a session bus, but distros and desktop environments didn't
provide a session bus yet because no programs relied on it.

However, that time is long past, and the D-Bus session bus is basically
desktop environment plumbing now: if someone doesn't have one, it's
probably because they have gone out of their way to not have one.
If that's the case, the use of dbus-run-session in that emacs launcher
might be because your users previously complained about a dbus-daemon
starting as a side-effect of something else and not getting terminated
afterwards (which is because we can't know who is about to connect
to its advertised address, and hence can't know when it's safe to
stop it). The other possibility for what to do here would be to not
install dbus-launch, not run dbus-run-session, and have uses of D-Bus
(such as GConf) in a session that didn't already start a dbus-daemon
just fail to work. Hopefully programs that don't strictly rely on it,
like Emacs, cope gracefully with that failure.

    S