Bug 183298 - flock always inherited across fork()
Summary: flock always inherited across fork()
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-28 00:52 UTC by JW
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-03-12 17:00:11 UTC
Type: ---
Embargoed:


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

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.]



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