[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
