Bug 199586
| Summary: | nfslock script starts statd before lockd is up so lock recovery fails | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jeff Layton <jlayton> | ||||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4.0 | CC: | steved | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-11-01 19:37:49 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: | 146773 | ||||||||
| Bug Blocks: | 198694 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jeff Layton
2006-07-20 16:24:07 UTC
Created attachment 132827 [details]
trivial patch to init script
Trivial patch that seems to fix the problem.
What confuses me is that nfslock no longer brings lockd up (or down) . The kernel does that when the server is started or the client mounts a fs, so I'm not sure how or why this fix works... Right -- lockd is now started by the 'nfs' script, so the only thing the nfslock script now does is start statd. The fix here is just to make sure that nfslock runs after the nfs script at boot time. Another (maybe better?) fix might be to do away with the nfslock script altogether and just have statd started by the 'nfs' script. Let me know if you think that's the way to go. Created attachment 132873 [details]
patch to move statd startup and shutdown into nfs.init
Something like this patch might be actually be a better way to go (though I've
not tested this patch as of yet).
This moves the rpc.statd startup and shutdown into nfs.init. With something
like this we can probably just remove nfslock.init from the package.
Alternately, we may just want to do this in the devel and or FC trees, and just
go with the chkconfig change for the existing RHEL releases.
I'd be OK either way...
Moving the starting of rpc.statd into the nfs init script would me the nfs server would have to be started every time the system booted (since statd is also needed by the client as well) which is not the right thing to do... imho... It seems to be that maybe nfslock should always bring up lockd so its started the same time rpc.statd is... Maybe by doing a 'modprobe lockd ' could cause the server to come up.... Also, maybe the bug could be tied with https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146773 since it may be related when it comes to failovers... Good point, I hadn't considered the client-side use of nfslock. Would there be any harm to simply making nfslock start later here? It seems like that would take care of the server-side case. Also, I'm not clear on what the effect would be on the server in starting lockd up before mountd/exportfs, etc. I've not picked through the code enough to know if server-side lockd would allow the client to reclaim a lock on a filesystem that's not yet exported. All that said, 146773 does look like a thornier problem. I'll go ahead and make this BZ dependent on that one. Any fix for this would be affected by that case anyhow, and we can just try to be cognizant of this problem as well to make sure that it gets addressed. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. > Would there be any harm to simply making nfslock start later here?
I believe so... statd has to be up and running before the netfs
initscript runs others the client locking side would break...
After further review, this is not a server bug... If the client stop trying to recover its locks just because the server has not made it up (yet) then that is a client bug, because the client should *never* stop trying to recover its locks... |