Question about isatty/read usage in dbus-launch
thiago at kde.org
Fri Dec 1 18:05:38 PST 2006
Brian Cameron wrote:
>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
To detect console sessions or sessions tied to a terminal.
>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.
Right. But this shouldn't tie it to the terminal if you start from a
display manager. stdin will be a file instead (~/.xsession-errors).
>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()
You can also do </dev/null. Much simpler than patching.
Now, why does the Solaris DM start programs keyed to a terminal that it
then closes? This doesn't make sense. If you're going to close it, don't
start programs associated with it. If you're starting programs, don't
>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).
Ok, I see it now. Actually makes sense.
Though I'd say the Ctrl+D is *specifically* intended to close programs. If
the intention was to keep those programs running, you wouldn't be sending
Ctrl+D, but blocking indefinitely on read. Send the Ctrl+D when the
session *actually* ends.
So I guess the behaviour is exactly what was intended by the Solaris
developers who left that comment. It's just not what you want for D-Bus.
>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).
Other two options:
eval `dbus-launch --exit-with-session < /dev/null`
or nothing. D-Bus now has the capability of auto-starting sessions.
>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:
> fork/exec dbus-daemon
> set suitable DBUS env vars
> 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
Sounds about right. I agree that it seems to be missing the "exit with
>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.
I see. It would be much simpler if dbus-launch was parent of both
dbus-daemon and of the executed program. There might be a reason for this
behaviour, though... It might be as simple as no one ever thinking about
it: dbus-launch --exit-with-session is meant to run as a daemon, which is
why it forks to the background.
>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.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061202/88b2c03e/attachment.pgp
More information about the dbus