Laca: I filed bug 6488506 in bugtaq against cde/cde/login category so that this will get fixed in /usr/dt/bin/Xsession. Once this happens, we will need to update our dtlogin-integration package to remove dbus-launch and ssh-agent stuff from Xintirc.jds. I'll keep an eye on making this happen in a coordinated way.
Brian > [Note: replying on jds-review where it belongs] > > Hi Brian, > > I vote for 1), all other options are just hacks. > > Thanks, > Laca > > On Wed, 2006-10-25 at 13:11 -0500, Brian Cameron wrote: >> Team: >> >> For the past few days I have been investigating why dbus-launch requires >> the dbus-03-dbus-launch.diff patch. Working with the D-Bus team, this >> patch should not be necessary. What this patch does is disables a check >> that D-Bus is running to see if it is actually connected to a terminal. >> This is used when the "--exit-with-session" argument is used so >> dbus-launch can tell when the session has exited and know when to exit. >> If we don't apply dbus-03-dbus-launch.diff, then D-Bus thinks that >> the session exits immediately, and kills the session daemon causing >> everything depending on D-Bus to not work. >> >> The problem seems to be caused by /usr/dt/bin/sdt_shell, which >> intentionally disconnects from the parent shell, as described >> in sys.dtprofile: >> >> # 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). >> >> That Control-D is causing dbus-launch to fail. So, how can we work >> around this problem: >> >> 1) Probably the best solution would be to move the dbus-launch >> command (and also the ssh-agent command) from Xinitrc.jds to >> /usr/dt/bin/Xsession so that instead of setting dtstart_shell >> to $DT_BINPATH/sdt_shell, we set sdt_shell to something >> like this: >> >> /usr/dt/bin/ssh-agent -- /usr/bin/dbus-launch --exit-with-session >> $DT_BINPATH/sdt_shell >> >> This fixes the problem, and also will mean that users will be able >> to run programs that depend on D-Bus (such as totem, yelp, etc.) >> from CDE sessions. The way we currently only run dbus-launch in >> the Xinitrc.jds file, dbus only gets started for JDS sessions. >> >> 2) We could hack /usr/dt/bin/Xsession so that it doesn't use sdt_shell >> when logging into JDS. Instead using, say, bash. Thus, avoiding >> the special sdt_shell logic. However, looking at the sdt_shell >> source code, it seems to be doing a lot of work setting up the >> terminal properly for Solaris. This may break things in weird >> ways. >> >> 3) We could also turn DTSOURCEPROFILE=false when logging into JDS. >> Probably not a good solution since some users probably want >> their .profile/.login file to be sourced. >> >> 4) Hack sdt_shell so that it doesn't send the Control-D when using >> JDS. >> >> 5) We could keep our hack to disable the read() check in dbus-launch, >> though this is hacky and may expose some weird problems since we >> won't be on the same page as Linux users. >> >> I think solution #1 is best. However, pretty much all of the >> solutions listed (aside from #5) require making the changes in the >> CDE code. So, I probably need to file a P1 bug against CDE to get >> this changed. I wanted to touch base with the other people on the >> team to see what people think the best solution is. Some of you >> might understand sdt_shell better than me and might have input? >> >> What do people think? >> >> Brian >
