Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 68720 - GConf can not handle stale locks if user home directory is on NFS volume.
GConf can not handle stale locks if user home directory is on NFS volume.
Product: Red Hat Linux
Classification: Retired
Component: GConf (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Aaron Brown
Depends On:
Blocks: 67217
  Show dependency treegraph
Reported: 2002-07-12 16:25 EDT by Eugene Kanter
Modified: 2007-04-18 12:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-08 15:12:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eugene Kanter 2002-07-12 16:25:57 EDT
Description of Problem:

GConf can not handle stale locks if usr home directory is on NFS volume.

How Reproducible:


Steps to Reproduce:
1. configure your home directory on NFS server. (autofs or /etc/fstab)
2. login
3. from the foot menu select reboot the system.
4. login

Actual Results:

GConf error dialog.

Expected Results:

no errors.

Additional Information:

~/.gconfd/ contains some .nfs* files
rm -rf ~/.gconfd and relogin solves the problem.
Comment 1 Havoc Pennington 2002-07-12 16:33:22 EDT
In general "handle stale locks" is an impossibility; if the lock is a lock, then 
it has to lock other things out; if other things can "handle" the lock, then
they wouldn't be locked out. If the lock is stale, that means it appears to be
locked but isn't; and if it appears to be locked then there's no way to tell
that it isn't. If you could tell, then it wouldn't be stale, it would just not
be a lock at all. ;-) Anyway. ;-)

Check a couple things:
 - is this a dup of bug #59245
 - are you running the nfslock service on both client and server
Comment 2 Eugene Kanter 2002-07-12 17:03:07 EDT
Well, it does look like a dup indeed.

"the clients tell the server that they have entered a clean new boot: the
server should drop the client's locks at that point." but something fails and
server does not drop the locks. I tried solaris 2.6 and red hat 7.2 as nfs
servers with identical results.

lockd is running of course.
Comment 3 Havoc Pennington 2002-07-12 17:11:49 EDT
You just rebooted normally though, no kernel crash or power buttons involved?
Comment 4 Eugene Kanter 2002-07-13 11:41:59 EDT
No crash of power button. GConfd is still running when shutdown initiated and
does not exit properly. That is why locks are left behind. Just follow my
scenario and you get the same results every time.
Comment 5 Toralf 2002-08-08 03:45:19 EDT
We are seeing the same thing here.

Question: Why isn't gconfd shut down properly on reboot?
Comment 6 Havoc Pennington 2002-08-08 11:17:25 EDT
gconfd should in theory get killall'd -TERM just like everything else on reboot. 
Comment 7 Eugene Kanter 2002-08-08 15:12:50 EDT
I have a feeling that NFS starts its shut down process before gconfd gets killed
by killall -TERM. There is apparently a (failing) attempt to kill gconfd by NFS
shutdown code since running gconfd prevents clean NFS umount.
Comment 8 Preston Brown 2002-08-21 13:19:42 EDT
We now pop up a dialog asking if you want to remove stale locks.

Note You need to log in before you can comment on or make changes to this bug.