Comment 17 for bug 592434

Created attachment 41262
Scope autolaunch to requesting client, don't connect to X server

Previously, when logging in via ssh with X forwarding, since
on most operating systems there is no DBUS_SESSION_BUS_ADDRESS,
we autolaunch a bus. In this is that dbus-launch will
connect to the remote X server and scope itself to that, which
will cause ssh to refuse to exit because there are still clients.

Basically:
ssh -X remotehost
firefox &
<Control-d>

Now, scoping of the bus is a long debated mess, but there is
a reasonable fix for the ssh -X case; we scope the bus lifetime
to the requesting client, not to the X server.

This patch adds --exit-after-clients-exit option to the bus, which
will cause the bus, after an initial connection is made once, to exit
after it has no connections.

dbus-launch --autolaunch is modified to use this. Now, in the
Firefox case what's actually going on is that it talks to GConf,
which was recently modified to scope to DBus, bus since no bus
is available it autolaunches one. The resulting gconfd-2 process
hangs around after ssh exits, but will eventually time out.

Possible regressions:
* Previously dbus-launch looked at the X server to try to find
  a bus address; this worked in the "local" (i.e. same uid-kernel)
  case where one manually sets:
  DISPLAY=:0 somedbusapp
  A specific example of this case is the legacy Unix getty. But
  I don't see this as a big problem; there are other environment
  variables, and really, the right fix for this is to have the
  OS default to single session.