bug#12112: 24.1.50; Starting emacs without dbus

[Harald Hanche-Olsen <hanche@math.ntnu.no>]

This is perhaps a documentation enhancement request,
or perhaps a feature request.

Background: emacs launches dbus if it is started under X11 (i.e., with
DISPLAY set). If the user logged into the machine via ssh, the dbus
process(es) will continue after emacs is terminated, thus holding open
a channel (or two) through the ssh tunnel to the X11 server. So ssh
hangs when the user tries to log out.

Therefore, there is a need for users to be able to either start emacs
without launching dbus in the process, or else making sure that dbus
is also terminated when emacs is terminated (if dbus was started by
emacs in the first place).

This can be achieved in the current code by compiling emacs with these
configure flags: --without-dbus --without-gsettings --without-gconf
However, this is very difficult to discover without extensive trial
and error. If this could be documented some place, it would be good.
Or perhaps the configure script should have an option that is
equivalent to this combination?

It would be even more desirable if the goal of running without dbus
could be achieved without a specially compiled binary. I know of just
one way to achieve that:

  DISPLAY= emacs --daemon
  emacsclient -c ...

This works because emacs does not launch dbus if it does not have
DISPLAY set in its environment. Perhaps that might be documented, too.

Yet another possibility: A special startup flag to stop emacs from
launching dbus, perhaps by unsetting DISPLAY in its own environment
during startup, then resetting it after all the code that might
conceivably launch dbus has run. (This may not be practical.)

I am seeing this problem in recent bzr revisions (as of yesterday and
today) on trunk.

All this has been discussed on the emacs-deval mailing list: See the
thread titled "Emacs insists on starting dbus?" starting on July 31,
2012.

In that thread it has been noted that the dbus maintainers have an
open issue surrounding this phenomenon:
https://bugs.freedesktop.org/show_bug.cgi?id=32509
However, a long time has passed without any acitivity, so it may not
be resolved on the dbus side for a while.

- Harald