Bob/Ghee/Laca: I think trying to clear the /var/tmp sockets files at session startup would be a disaster. It would be hard to make this work properly for users who are logged into multiple sessions (Login via Nested Window, XDMCP, multiple heads, SunRay, etc.).
It might be nice if we cleared them away at boot time. These temp files seem to cause the most problem when they are left over from before the machine was started. Probably the best way to do this would be to simply set up a SMF service that starts up at boot time and clears away the files only when it is started at boot time. Perhaps we could use one of our existing services that starts at boot time, such as D-BUS to do this when it starts? Thought it would probably be better to make a new service, probably. Brian >> On Fri, 2006-08-11 at 10:59 +0100, gheet wrote: >> >>>> Is it not possible to clean out the /var /tmp files in the >>>> preliminary scripts in /usr/dt/config that starts a >>>> gnome-session before actually starting a new gnome -session >>>> for a particular user or why has this not been done ? >>> Doing it with a script in /usr/dt/config implies dtlogin is the >>> login manager and that does not work with gdm as login manager. >>> >> >> That's not true, actually. gdm starts jds by running >> /usr/dt/config/Xsession.jds. See /usr/share/xsessions/gnome.desktop >> >> >>> Doing this in gnome-session may be the common place to put it before >>> gconfd-2 is started. Of course there is the consideration that the >>> user has login in more that once, one with Sun Ray card, the other >>> with non Sun Ray card. >>> >> >> Hmm... I don't think putting hacks that clean up the dirt in >> gnome-session or the session startup files is the right fix... >> >> 1) gconf should not fall over if stale locks or sockets are left behind >> 2) gconf should clean up its own mess >> >> I've already logged 6425609 ORBit2 leaves stale sockets in /var/tmp >> Is there one for gconf? >> > > I agree with the approach suggested above. > > Ghee raises a good point to keep in mind, however, > no matter how we fix this: Users may create > multiple desktops on a given server or on a > network sharing a single home directory. This is > true with Sun Ray, VNC, "Remote login" (XDMCP), > and a variety of other mechanisms. Gnome needs to > be robust about handling this situation. > > What's unique in these situations is the $DISPLAY > specification. Perhaps temp pathnames should always > embed $DISPLAY in the name to avoid collision. > It's impossible to have two active desktops with the > same $DISPLAY, even though you can have multiple > active desktops with the same $USER. > > -Bob > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org
