Bug 183298
Summary: | flock always inherited across fork() | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | JW <ohtmvyyn> | ||||
Component: | util-linux | Assignee: | Karel Zak <kzak> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Ben Levenson <benl> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4 | Keywords: | FutureFeature | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Enhancement | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-03-12 17:00:11 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: | |||||||
Attachments: |
|
Description
JW
2006-02-28 00:52:04 UTC
Created attachment 125364 [details]
Patch to add --fcntl option to flock
The --fcntl option allows choice between flock() and fcntl() locking semantics.
Especially pertient is the behavior of locks across fork(), and over NFS.
Ideally, however, the flock() call would have a flag that could control fork()
behavior.
Well, feedback from "H. Peter Anvin" <hpa (at) zytor.com> who is the flock command author about the patch: Okay, there seem to be several reasons *NOT* to do this at this time; I tried it out experimentally and found several problems: a) the semantics of POSIX locks (the proper name for fcntl locks) when it comes to closing a file descriptor is at very best cantankerous; closing *any* file descriptor associated with the locked file drops the lock. b) POSIX write locks require write permission and a file descriptor opened for writing; flocks do not. c) There seems to be a bug in the Linux kernel with regards to F_SETLKW and signals; it doesn't take the itimer signal and return with EINTR; instead it waits indefinitely. This is very bad, since it means not only doesn't --wait work correctly, but the process is unkillable! [Please, continue in this discussion directly with Peter and with upstream maintainers. Thanks.] |