Ah. Something I can answer. I write mail filtering software primarily
and locking files across NFS mounted partitions becomes a necessity in
that world.
The problem with placing lock files on NFS mounted partitions is the
locking mechanisms used by most UNIXes are not properly respected across
NFS. flock and fcntl claim to be (BSD's lockf does not) but that is not
always reliable. Further, clock skew (different hosts realizing different
time differentials for files due to their own clock differences) makes
things dicey.
Mailers like Pine and Elm generally test for a lockfile of the form
"username.lock" and, if one is absent, create it, establish a lock on it,
do their work, and remove it. The file stands as a marker that an update
is in progress and others processes should block until it is gone.
Elm and, in particular, procmail, take an even more hard line approach,
creating a lock file, then applying flock and fcntl style locks (and
lockf, for what it's worth) to it. The techniques are generally very
successful, provided care is exercised to avoid deadlock conditions where
one process is waiting on another to release a lock which it, in turn, is
unable to release due to another event.
Further, placing lock files on NFS mounted partitions exposes them to the
possibility that some ill-behaved program on another host would discover
them as evidence of a deadlock and graciously clobber the file.
The long and the short of it is, there are no strong, reliable file
locking mechanisms which work across NFS. Lock files are best located on
local drives, except in cases of mail reading and delivery where lock on
NFS filesystems are an unavoidable headache.
Wyman
On Thu, 2 Jul 1998, Dave Finnegan wrote:
> Apologies in advance for posting a pure Apache question
> to the apache-ssl list ... is there an apache mailing list?
>
> The apache documentation talks about placing lock files
> on local disks and not on NFS mounted file systems.
> However, there is no mention of the reasons behind this
> stern warning.
>
> I'd be very interested in information as to why this is such
> a bad thing to do.
>
> TIA,
>
> Dave
> dave@syncinc.com
>
>
Wyman Miles
Systems Administrator, Systems and LAN Management, Rice University, Texas.
(713) 737-5827, e-mail:wymanm@rice.edu, pager:wymanm@pager.rice.edu
SalMoN AntiSpam software for UNIX: http://is.rice.edu/~wymanm/smn