smcv at collabora.com
Mon Apr 10 11:37:18 UTC 2017
On Fri, 07 Apr 2017 at 17:59:32 -0700, Thiago Macieira wrote:
> Em sexta-feira, 7 de abril de 2017, às 04:49:37 PDT, Simon Lees escreveu:
> > 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.
> We're not.
> $ echo $DBUS_SESSION_BUS_ADDRESS
> $ emacs
> Activating service name='org.gnome.GConf'
> Successfully activated service 'org.gnome.GConf'
So the issue here seems to be that the emacs launcher is second-guessing
how dbus-launch works:
and preferring to use dbus-run-session if both dbus-launch and
dbus-run-session are available.
This is not the right thing to do. If dbus-launch is installed, libdbus
will *already* do the right thing, without emacs needing to reimplement it.
Please raise this with the openSUSE maintainers of emacs. This
appears to be a distro-specific issue in code introduced for a particular
If openSUSE's emacs packaging really needs to do these tricks, it could
avoid this failure mode by looking for $XDG_RUNTIME_DIR/bus, and if it is
present and owned by the right uid, using it. (dbus-launch --autolaunch
already does that.)
The emacs wrapper says
# Now check for valid dbus, e.g. after su/sudo/slogin
which suggests that this is an elaborate workaround for one or both of
* lacking a session bus and wanting to work around it by borrowing the
session bus from the "wrong" login session; under the strict login session
model (artificially separate login-sessions) this is just wrong, while
under the user-session model it is unnecessary
* escalating privileges without clearing the environment (su, not su -),
which can be fixed by clearing the environment correctly
> It seems the problem is that the session bus launched by whatever the distro
> uses did not fill in ~/.dbus/session-bus/$MACHINEID-0.
Correct, the systemd user unit does not fill in ~/.dbus/session-bus.
I would really prefer not to keep that mechanism forever - we have already
been asked to stop putting this "autolaunch crap" in the home directory
<https://bugs.freedesktop.org/show_bug.cgi?id=35887>. I had hoped that
the user-session service (which is already opt-in, so openSUSE's dbus
maintainer should hopefully have evaluated its impact before opting in)
was an opportunity to draw a line and get away from those historical
More information about the dbus