Bug 183298 - flock always inherited across fork()
flock always inherited across fork()
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-27 19:52 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-12 12:00:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add --fcntl option to flock (2.39 KB, patch)
2006-02-27 19:55 EST, JW
no flags Details | Diff

  None (edit)
Description JW 2006-02-27 19:52:04 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.
Comment 1 JW 2006-02-27 19:55:31 EST
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 12:00:11 EST
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.]

Note You need to log in before you can comment on or make changes to this bug.