Re: pidfile_lock(3)

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

On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote:
> On Sun, Mar 20, 2016 at 08:53:03PM +0000, Roy Marples wrote:
> > On Sunday 20 March 2016 14:53:46 you wrote:
> > > On Sat, 19 Mar 2016 23:29:37 +0000
> > > 
> > > Roy Marples <roy%marples.name@localhost> wrote:
> > > > pidfile(3) is pretty crap - it just writes to the file without any
> > > > locking.
> > > 
> > > I don't understand why you think any of that matters.  Locks only
> > > advisory anyway.  Any noncooperating process can (with sufficient
> > > privilege) overwrite the file.  What cooperating process do you imagine
> > > would honor a lock on a pidfile?
> > 
> > So it honors it's own lock to avoid user stupidity of starting the same daemon 
> > more than once. This is the primary goal of the function.
> 
> That's the wrong way to do it, because it does not work reliably on NFS.
> You can take advantage of O_CREAT|O_EXCL or rename() semantics to do the
> same thing but in a much more robust way.

In fact, what you really want is just the guts of shlock(1), specifically
the shlock -p behavior.  I can't see any reason why pidfile shouldn't just
do exactly what shlock -p does, except with a C rather than a shell interface.

-- 
  Thor Lancelot Simon	                                     tls%panix.com@localhost

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart