Bug 68720
Summary: | GConf can not handle stale locks if user home directory is on NFS volume. | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Eugene Kanter <ekanter> |
Component: | GConf | Assignee: | Havoc Pennington <hp> |
Status: | CLOSED RAWHIDE | QA Contact: | Aaron Brown <abrown> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | edoutreleau |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-08-08 19:12:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 67217 |
Description
Eugene Kanter
2002-07-12 20:25:57 UTC
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 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. You just rebooted normally though, no kernel crash or power buttons involved? 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. We are seeing the same thing here. Question: Why isn't gconfd shut down properly on reboot? gconfd should in theory get killall'd -TERM just like everything else on reboot. 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. We now pop up a dialog asking if you want to remove stale locks. |