Red Hat Bugzilla – Bug 183298
flock always inherited across fork()
Last modified: 2007-11-30 17:11:25 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217 Description of problem: flock utility always preserves its lock across fork()'s. This behavior should be controllable. For example, when using flock to control access to a script which starts a daemon, it isn't always desirable to have that daemon hold the lock forever. Version-Release number of selected component (if applicable): util-linux-2.12p-9.12 How reproducible: Always Steps to Reproduce: 1. cat >/tmp/flocktest <<END #!/bin/sh /etc/rc.d/init.d/named restart END chmod +x /tmp/flocktest flock /tmp/flocktest /tmp/flocktest 2. flock /tmp/flocktest /tmp/flocktest Actual Results: Step 2 blocks until named restarted. Expected Results: It should be possibly to have flock lock access to the script (/tmp/flocktest), without detached child processes also holding the lock. Additional info: The problem arises because of the different ways flock() and fcntl() behave across a fork(). In the first case the lock is always inherited, and in the second case it is not. There is no explicit control over this.
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.]