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: > > r...@marples.name (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
