On Fri, 2006-08-11 at 13:03 -0500, Brian Cameron wrote:
> 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.).

I agree with this...

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

... but disagree with this one.  It suspiciously sounds like a popular
desktop operating system where you have to reboot if something goes
wrong.  Rebooting a sunray server is not something sysadmins will
want to do.  It should Just Work[tm].  We probably need to fix GConf,
ORBit2, whatever else that leaks files or sockets.

Laca

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


Reply via email to