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
kris at obsecurity.org
Sun Apr 1 20:10:13 UTC 2007
The following reply was made to PR bin/111101; it has been noted by GNATS.
From: Kris Kennaway <kris at obsecurity.org>
To: "R. B. Riddick" <arne_woerner at yahoo.com>
Cc: Kris Kennaway <kris at obsecurity.org>, freebsd-gnats-submit at 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 16:04:28 -0400
On Sun, Apr 01, 2007 at 12:59:53PM -0700, R. B. Riddick wrote:
> --- Kris Kennaway <kris at obsecurity.org> wrote:
> > On Sun, Apr 01, 2007 at 06:41:43PM +0000, Arne Woerner wrote:
> > > 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.
> OK - recommendation withdrawn...
> > It appears that lockf is working as designed, and also as explicitly
> > documented. It looks like no action can be taken here.
> Explicitly? Documented? Since I have not found that documentation, can u help
> me a little bit by showing it?
> In the mean time I show a piece of my documentation (man page lockf(1)):
> The lockf utility acquires an exclusive lock on a file, creating it if
> necessary, and removing the file on exit unless explicitly told not to.
This is even underlined.
> While holding the lock, it executes a command with optional arguments.
> After the command completes, lockf releases the lock, and removes the
> file unless the -k option is specified. BSD-style locking is used, as
> described in flock(2); the mere existence of the file is not considered
> to constitute a lock."
> I repeat: "CREATING IT IF NECESSARY"
> If think, the explicit documentation says, that the file is created (although
> this "if necessary" is somewhat weaselish, so that the man page should be
> changed, too; it should say: "creating it if it does not exist").
But that is what "if necessary" means.
> Currently without the "-k" option given only the first conflict is solved
> properly, while the next is not, which is surely not what we want, and which is
> surely nowhere documented.
If you would like to submit a manpage change to expand upon the
problems that can occur when not using -k, please go ahead.
More information about the freebsd-bugs