bug#14474: 24.3.50; Zombie subprocesses (again)

[Paul Eggert <eggert@cs.ucla.edu>]

A workaround, for me at least, is to propagate the
DBUS_SESSION_BUS_ADDRESS environment variable into
the child process with a different userid.  

For example, here is a failing session, where I became the user 'exp'
and later observed the problem in a shell window:

$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bpx4rxPk7z,guid=6e491bf38a5b2b6fce17d0a251a221bf
$ sudo sh
# su exp
$ env | grep DBUS
$ emacs
** (emacs:15115): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-x2KgryK9C8: Connection refused

And here is a session that worked.  The key difference is that
I used su's '-E' option:

$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bpx4rxPk7z,guid=6e491bf38a5b2b6fce17d0a251a221bf
$ sudo -E sh
# su exp
$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-bpx4rxPk7z,guid=6e491bf38a5b2b6fce17d0a251a221bf
$ emacs
** (emacs:15441): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-x2KgryK9C8: Connection refused

In both cases, the dbus library complains to stderr that it can't connect
to /tmp/dbus-x2KgryK9C8 (I don't know where it's getting that name from).
When DBUS_SESSION_BUS_ADDRESS is unset, the dbus library arranges to run
the shell script /usr/bin/dbus-launch, which seems to cause the problem.
But when DBUS_SESSION_BUS_ADDRESS is set, the dbus library falls back
on its contents and doesn't invoke dbus-launch.