Re: gconfd errors w/nfs mounted homedirs

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes:
>  I'm trying to figure out a way around this problem or at least a better
> explanation:
> 
> I've got 100+ systems mounting their homedirs over nfs. If a user logs
> into one, then logs into another one nautilus and galeon won't work
> complaining about gconfd locking problems. So I look in ~/.gconfd in the
> user's homedir and I see the dir lock - inside there I typically see a
> file named ior and sometimes a stale .nfs[numbershere] which is
> typically an outstanding nfslock.
> 
> if I remove that dir/all of those files then the user's login will once
> again work.

Well, except they'll lose config settings since they'll have two
gconfd processes writing over each other.

> Now the fun part is that even if the user logs out of the other system
> gconfd is typically still running as the user and it hangs around
> indefinitely. If I kill it then it goes away and so does the outstanding
> lock.

It doesn't hang out indefinitely; it was originally 15 minutes I
think, and has been steadily going down to the current 2 minutes.
I've been thinking of switching to 1 minute or 30 seconds. I'm not
sure which exact versions have which timeout.

It hangs around a bit just to avoid "thrashing" where it starts and
stops over and over if you are running a script that does gconf
things.

> Is there a reason for this behavior? I thought about looking through
> gconf to see about forcing the lock file to be made in /tmp like orbit
> does with its cookies. But I wanted to know if this interaction was
> intentional and what I could do about it.

/tmp doesn't work, because config settings are per-user. /tmp is
per-machine. So if you used /tmp you could start two gconfd, but they
would overwrite each other's files.

The way it's supposed to work is that if I log in to machine A, then
to machine B, then processes on machine B should contact the gconfd on
machine A. However there is a bit of a glitch in that ORBit disables
TCP/IP networking by default.

To enable TCP/IP, add the line ORBIIOPIPv4=1 to /etc/orbitrc and
restart everything. That _should_ work, if it doesn't then there's a
bug to fix.

Be sure you're using at least gconf 1.0.7 of course - though it sounds
like you are.

Havoc