Question about isatty/read usage in dbus-launch
Brian.Cameron at Sun.COM
Fri Dec 1 17:25:08 PST 2006
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
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()
The following comments from /usr/dt/config/sys.dtprofile explain how
sdt_shell works and passes the Control-D back to the terminal that
### 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:
set suitable DBUS env vars
fork/exec <program> (incl vars)
wait for signs of exit (X died, or EOF on tty)
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:
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`
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
So, what do people think? Thanks for helping with this.
More information about the dbus