Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!wuarchive!psuvax1!rutgers!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions
Subject: Re: lockfile type locks
Message-ID: <1990Jul12.144815.28842@chinet.chi.il.us>
Date: 12 Jul 90 14:48:15 GMT
References: <1990Jul5.145451.28108@chinet.chi.il.us> <2699D97F.EF5@tct.uucp> <CEL4GPE@xds13.ferranti.com>
Organization: Chinet - Public Access UNIX
Lines: 22

In article <CEL4GPE@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In practice, storing a PID in the file and doing a kill() on it may give
>false positives, but they're usually harmless. It will never give a false
>negative (well, except over a network... in which case kernel locking is
>likely a lost cause as well).

The non-harmless case of a false positive is where 2 or more processes
test an existing lockfile as the owning process exits.  Both decide
that the lock is stale, one creates its own lock, then the other process
completes its unlink() which now affects a valid file.

>The problem with kernel locking is all the incompatible "standards".

Right - in the case of a mail delivery agent, it has to agree with
the readers that may delete or write back the spool file, and the
source to all such programs running on the machine may not be available.
I've added a test to prevent unlinking lockfiles less than a couple of
minutes old which should greatly reduce the possibility of trouble, but
it still makes me a little queasy...

Les Mikesell
  les@chinet.chi.il.us