Date: Sun, 1 Apr 2007 20:00:17 GMT From: Kris Kennaway <kris@obsecurity.org> To: freebsd-bugs@FreeBSD.org Subject: Re: 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 Message-ID: <200704012000.l31K0H30074770@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/111101; it has been noted by GNATS. From: Kris Kennaway <kris@obsecurity.org> To: Arne Woerner <arne_woerner@yahoo.com> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: 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 Date: Sun, 1 Apr 2007 15:53:08 -0400 On Sun, Apr 01, 2007 at 06:41:43PM +0000, Arne Woerner wrote: > >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... We cannot do that, not using -k is required in some situations, so those scripts will break. It appears that lockf is working as designed, and also as explicitly documented. It looks like no action can be taken here. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704012000.l31K0H30074770>