dbus-run-session output.

[Simon McVittie]

On Wed, 12 Apr 2017 at 13:33:22 +0930, Simon Lees wrote:
> the one place we don't currently start [dbus-daemon] is for ssh
> sessions, which maybe we should especially if people are using x
> forwarding.

Note that in the user-session case, if $XDG_RUNTIME_DIR/bus exists, it is
not necessary for a dbus-daemon to be *running* until you actually try to
connect to it: systemd --user can use socket activation to start the
dbus-daemon lazily. For a real test you would have to try to start a
D-Bus client, for which "dbus-monitor --session" is a simple example
(interrupt with ^C to exit).

Let's say I am on machine "workstation" and I run "ssh -X appserver emacs",
with uid 1000 on appserver.

In the user-session case, emacs should be sharing
appserver:/run/user/1000/bus with any other concurrent
login sessions (graphical, tty, ssh, whatever) by uid 1000 on
appserver - the socket exists as long as uid 1000 has at least
one login session open. $DBUS_SESSION_BUS_ADDRESS should either
be unix:path=/run/user/1000/bus or unset (setting it is preferred,
to be nice to non-mainstream D-Bus implementations and packages that
second-guess how D-Bus works). When a client tries to connect to that
socket, systemd will start dbus-daemon --session as a side-effect.

In the dbus-launch --autolaunch case (dbus-x11 package on Debian, and I
think on openSUSE too), $DBUS_SESSION_BUS_ADDRESS will not initially
be set. When a client tries to connect to the session bus, libdbus or
GDBus will try /run/user/1000/bus, fail, and fall back to starting
dbus-launch --autolaunch, which ends up starting one dbus-daemon per
(machine, user) pair per X11 display; the machine in this case is
appserver, not workstation, and the dbus-daemon is started on appserver.

pam_systemd is normally what's responsible for setting up the
XDG_RUNTIME_DIR and the "systemd --user" instance on appserver.

    S