Re: dbus-run-session output.

Simon McVittie <smcv-ZGY8ohtN/[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <[email protected]>
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
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.