[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Gconfd startup errors at GNOME login

On Thu, 2002-10-10 at 20:41, Havoc Pennington wrote:
> In 8.0 you can also do "export GCONF_LOCAL_LOCKS=1" in a script in
> /etc/profile.d, but there's a denial of service attack where users can
> prevent each other from logging in by creating someone else's lockfile
> in /tmp. If you're not concerned about that you can avoid NFS locking
> entirely.

Oh excellent.  These users barely have a clear concept of what Linux is
much less such topics as /tmp.  I don't think I have anything to worry
about. :)

> > I suspect that the problem is linked to (but not necessarily exclusive
> > to) users doing unexpected poweroffs/reboots. 
> That's what causes 59245.

Probably related then.  I might try to gather some more precise evidence
by testing this situation myself under controlled situation and report
my findings on that bug.  

These users are all coming from a Windows world and whenever anything
has been acting not how they expect it to I think they have been hitting
the power and reset buttons.  I will have to continue with my user

> > Also, if the user asks
> > for a reboot via the Gnome menu gconfd seems to still be running when
> > the shutdown script gets to forcing NFS unmounts.  That can't be
> > good.
> That shouldn't matter (other than it slowing down the shutdown).

Okay.  I thought that might result in the same situation as a an abrupt
poweroff/reset with the stale lockfiles.

> > Would a user logging in at multiple stations at once cause this too?  I
> > have ORBIIOPIPv4=1 in /etc/orbitrc but I'm not sure if it's working
> > because none of the workstations appear to be listening on any
> > additional TCP or UDP ports.
> Multiple logins might cause other issues, but I don't think it would
> cause this one. You can easily check if the orbitrc thing is working; 
> "gconftool-2 -R /apps/metacity" or something on two machines with same
> user home directory, see if there's only one gconfd-2 process between
> the two machines, and the gconftool call works.

These machines are all currently on RHL 7.3 so I only have gconftool-1
available but I tried it with "gconftool-1 -R /apps/nautilus".  It
appears to work perfectly.  I only see the gconfd process start up on
whichever machine I run the command on first.

> > The last entry on bug #59245 was on July 6th without any clear
> > resolution... Do you think that this issue has been dropped?
> Just waiting to make it to the top of the priority queue of someone
> who understands NFS.

Fair enough.  I might ask around on the NFS list about this issue.  I've
been following (though not necessarily always understanding :) it for
quite a while now.

Thanks for all your assistance Havoc, it is very appreciated.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]