Re: pidfile_lock(3)

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Thu, 24 Mar 2016 07:18:13 +0000 (UTC)
mlelstv%serpens.de@localhost (Michael van Elst) wrote:

> roy%marples.name@localhost (Roy Marples) writes:
> 
> >See here:
> >http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html
> 
> ... handling crashing programs reliably
> 
> isn't a worthwhile goal to me.

I don't understand that line of thinking.  

Programs terminate abnormally all the time.  It doesn't have to be a
program crash.  It could be signalled; it could be signalled by a
sysadmin other than the one currently looking at the pidfile.  

The crash may also originate in a library.  Libraries are increasingly
developed on Linux where the default configuration supports
overcommitted memory.  Because malloc never fails, it's not unusual for
it not to be tested, or for the error path to be broken.  On NetBSD it
will fail, of course, and down will come baby, cradle and all.  

Resources allocated by the OS -- memory, file descriptors, etc. -- are
cleaned up automatically, whether or not exit(3) is called.  If they
weren't, would you still feel the same way?  

Pidfiles and tempfiles are examples of resources that are not allocated
by the OS and are not cleaned up automatically.  Stale pidfiles in
particular are misleading to the point of dangerous insofar as they
tempt the admin to kill the wrong process.  No one considers that
desirable.  What I find baffling is saying it's OK.  Why?  Because worse
is better?  Because tradition?  

I reject the comparison to systemd.  A tiny daemon to manage pidfiles
is exactly what systemd is *not*.  It does not bind together a bunch of
different services.  It does not require anything be rewritten.  It
does not require it even be used, if fallback to current behavior is
supported.  What it does do is fix a recognized problem in the most
minimal way possible.  

--jkl