bin/111101: /usr/bin/lockf: when lockf blocks due to another lockf
and no -k is specified and the other lockf ends, the file is away
Arne Woerner
arne_woerner at yahoo.com
Sun Apr 1 18:50:05 UTC 2007
>Number: 111101
>Category: bin
>Synopsis: /usr/bin/lockf: when lockf blocks due to another lockf and no -k is specified and the other lockf ends, the file is away
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Apr 01 18:50:04 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator: Arne Woerner
>Release: R6.2
>Organization:
>Environment:
FreeBSD neo.riddick.homeunix.org 6.2-RELEASE FreeBSD 6.2-RELEASE #8: Fri Mar 30 10:00:56 UTC 2007 aw at neo.riddick.homeunix.org:/usr/src/sys/i386/compile/NEO i386
>Description:
I use lockf in order to coordinate the access to my TV frame grabbers (/dev/cxm?).
When another recording starts (process B) it can happen that a previous recording (process A) still needs some seconds, I end up with an unlink-ed lock file.
I would expect the following order:
1. process A: holds file LCK
2. process B: blocks on file LCK
3. process A: unlinks file LCK
4. process A: releases lock on file LCK
5. process B: locks the already opened but unlinked file LCK
6. process B: checks, if file LCK still exists
7. process B: creates file LCK
8. process B: locks file LCK
As a workaround I use lockf with option "-k", which should solve that problem...
Furthermore I would like to recommend, to make the "-k" behaviour the default behaviour, so that we will not remove data files, that were co-used as lock files...
-Arne
>How-To-Repeat:
Let LCK be a file, that does not exist in the work directory
% lockf LCK sleep 10 & sleep 1 ; lockf LCK ls -l LCK
[1] 38788
ls: LCK: No such file or directory
[1] + Done lockf LCK sleep 10
I was able to repeat that on a i586 (Pentium) and a i686 (Athlon XP), which both used R6.2 with multimedia/pvr250 related kernel patches.
>Fix:
1.
Use "-k" as a work around.
2.
Check if file exists after holding the lock. And if it doesnt exist anymore, re-create it and close the old (in the meantime unlinked) lock file and start again... <-- Maybe that contains another error, that I dont see yet...
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list