gconfd errors w/nfs mounted homedirs

[seth vidal <skvidal phy duke edu>]

Hi all, 
 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.

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.

However this is not a good state for things for us. I need some way of
making it possible that a user can login at two locations - they know
they are not supposed to do this that they COULD get corrupted config
files but they may do so anyway. Moreover if they do logout and gconfd
hangs around then they've done all things right but gconfd is screwing
things up for them. 

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.

thanks
-sv