Re: pidfile_lock(3)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Thu, Mar 24, 2016 at 11:55:25AM +0000, Roy Marples wrote:
> Lets go back to the original question.
> 
> On 20/03/2016 09:26, Michael van Elst wrote:
> > roy%marples.name@localhost (Roy Marples) writes:
> > 
> >> So I've created pidfile_lock (patch attached) to address these problems.
> > 
> > Does it work on NFS root?
> 
> After taking on board what everyone has said, my considered answer is thus:

[Proceeds to insist that other people stop knowing things about NFS that
 have been common knowledge for 30 years]

POSIX file locking over NFS is unreliable.  The protocol has been, IIRC,
mathematically proven incorrect, but in any case, it relies on userspace
daemons on client and server which just never seem to work all that well.

Nobody is going to wave a magic wand and "fix" this.  But in practice, it
doesn't matter, because applications that really care about performance
for mutual exclusion around file resources use local storage, while for
applications where performance doesn't matter, there are time-honored
solutions that *don't* rely on protocols with questionable design and
implementation to work both locally and remotely, like the file-based
ones used by mail clients, newsreaders, UUCP, etc. for decades.  These
come in many flavors to address many ancillary concerns, ranging from
"just touch the file" to "write the PID" to "write the PID and hostname"
to "write the PID, hostname, and process title".  But the point is, it
would be nice if doing it the other way worked, but it doesn't (indeed,
it doesn't to the extent of now proposing to guck up the system with a
whole new process (systemd is ----->over there if you really want it)
just to manage resources associated with doing it the other way.

Ultimately, locking is broken for lots of filesystems -- don't even
get me started on FUSE and similar abominations -- but a filesystem
that doesn't support atomic link is so non-POSIX that it basically
won't work for anything but trivial use.  Defensive programming says
to do it the way that works most everywhere -- not the way that looks
"clean" at first glance.

Ugly it is, but relying on exclusive file creation and rename, and
actually looking at the contents of the files, _works_.  It is the
standard tool for this in the Unix programmer's toolbox.  Gyrations
to do something different, motivated by buggy code, are not very
surprisingly going to evoke the response "fix the code, don't break
my OS to accomodate it".  So I think there is a lot of talking past
each other going on.

Thor