Question about isatty/read usage in dbus-launch

[Brian Cameron]

D-Bus experts:

I was wondering if people could explain why D-Bus uses isatty()
and waits for read() to return a Control-D to tell when the user session
has ended.

This logic is in tools/dbus-launch.c in the function
kill_bus_when_session_ends().  My understanding is that this function is
used when dbus-launch is started with the --exit-with-session argument.
dbus-launch is normally called with this argument when starting the
GNOME desktop session so that programs which depend on D-Bus will work
in the user's session.

For various reasons this is causing a bit of a headache.  We now know
that the reason dbus-launch fails on Solaris is because the
/usr/dt/bin/Xsession script starts the user session with a Solaris
specific program called sdt_shell, and this program is responsible
for sending a Control-D back to the controlling terminal which
dbus-launch thinks incorrectly is the session exiting.  We work around
this problem by patching dbus-launch to avoid doing the isatty()/read()
tests.

The following comments from /usr/dt/config/sys.dtprofile explain how
sdt_shell works and passes the Control-D back to the terminal that
started it:

###   The desktop reads the .dtprofile and .profile/.login with a
###   simulated terminal via the sdt_shell program.  The sdt_shell
###   program will create a controlling terminal.  Shell output will be
###   logged to the location $HOME/.dt/startlog.  Any shell requested
###   input will receive an end of file character (Control-D).

My hope was that we could fix this problem by fixing the Xsession
script so that we call "dbus-launch --exit-with-session sdt_shell [...]"
which works fine) rather than calling dbus-launch inside a shell started
with sdt_shell (which does not work).

However, we are getting pushback from the Sun CDE team about changing
the behvior of how /usr/dt/bin/Xsession works.  The following comments
and questions and I am hoping someone from the D-Bus team can explain if
the isatty()/read() logic is really needed or if it would be better to
enhance D-Bus as suggested below to avoid using isatty() and read():

---

I honestly think that things are over complicated for the specific case
in question - where dbus-launch <program> is called - it should be a
simple matter that if <program> exits then dbus-launch should then kill
the daemon started specifically for that program - maybe there is a
need for an --exit-with-program flag to achieve this.

 From what I can see, when dbus-launch is called with a program
parameter, it seems to do something like:

	dbus-launch
		fork/exec
			fork/exec dbus-daemon
	   set suitable DBUS env vars
		fork/exec
			fork/exec <program> (incl vars)
	   if --exit-with-session
		wait for signs of exit (X died, or EOF on tty)
		if found
			kill dbus-daemon
		exit

What really I don't like about this is the disconnect between
dbus-launch and the program that was executed, I can understand why you
might want this for the dbus-daemon but not for the program.

As it stands both dbus-daemon and <program> are now children of init
(pid 1) - which seems wrong to me.

If I run the command:

	dbus-launch bash

Many would expect that, like ssh-agent, the daemon started would be
killed when bash itself exited, not when the tty it's on exits -
multiple calls to the above will result in lots of dbus-daemon
processed running. Even if I add the --exit-with-session flag - these
processed will remain intact until I finally kill the terminal window
that owns the tty.

The --exit-with-session seems to be totally targeted at an X session,
which could have been much easier to handle by not having the program
being disconnected from the dbus-launch process - but as I say, if you
happen to call :

	eval `dbus-launch --exit-with-session`
	/usr/bin/gnome-session

Then that's a different scenario to me, and warrants the behaviour
currently exhibited by dbus-launch.

What I'm really saying is that the two mechanism need to be treated
differently.

---

So, what do people think?  Thanks for helping with this.

Brian