Bug 183298

Summary: flock always inherited across fork()
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED UPSTREAM QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4Keywords: 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 Flags
Patch to add --fcntl option to flock none

Description JW 2006-02-28 00:52:04 UTC 
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.
Comment 1 JW 2006-02-28 00:55:31 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.
Comment 2 Karel Zak 2006-03-12 17:00:11 UTC 
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.]