dbus-run-session output.

[Simon McVittie]

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 
> unix:path=/run/user/1000/bus
> $ 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:
https://build.opensuse.org/package/view_file/openSUSE:Factory/emacs/emacs.sh?expand=1
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
distribution.

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
these situations:

* 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
oddities.

    S