Question about isatty/read usage in dbus-launch

[Thiago Macieira]

Brian Cameron wrote:
>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.

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()
>tests.

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 
close it.

>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).

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:
>
>	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

Sounds about right. I agree that it seems to be missing the "exit with 
program" option.

>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.

Agreed again.

-- 
  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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061202/88b2c03e/attachment.pgp