Re: pidfile_lock(3)

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

On Mon, 21 Mar 2016 10:55:49 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> Please do not introduce a daemon just to service pidfile.  

Do one thing and do it well?  

It need not be a new daemon.  The functionality could attach to
syslogd, for example, or init....  

I know you understand the motivation: to avoid signalling the wrong
pid.  The race condition -- the time between inspecting the pidfile and
sending the signal -- can't be extinguished without a name-based
syscall or a superhost a la systemd -- but it can be minimized.  And
the new daemon could be extended to serve other daemon-management
purposes.  

How would you solve the problem of stale pidfiles?  Or do you not agree
that's their main pitfall?  

I suppose NFS is a problem if you monitor daemons on a netbooted
server, some kind of weird small box.  A daemon would give you a shot
at getting that right, too, on the syslogd model.  

I don't want to make a mountain out of a pidfile.  I'd just like to
understand your thinking better, because to me "just to service
pidfiles" isn't a priori too little cause for a daemon.  

--jkl