Re: pidfile_lock(3)

[mlelstv%serpens.de@localhost (Michael van Elst)]

dyoung%pobox.com@localhost (David Young) writes:

>I'm not sure that the problem of pidfile(3)-using crashing programs is
>serious enough on its own to justify changing the kernel.

The standard usage is:

system bootstrap removes pidfiles (or uses empty tmpfs)
daemon creates pidfile exclusively on startup and fails if pidfile exists.
daemon removes pidfile on regular exit
crashes require explicit (usually manual) checking and cleanup.

There is no common way to identify wether a pidfile actually matches
a running process. It usually depends on the specific daemon. Checks
usually include some heuristics:

- syntax of the pidfile
- pid exists
- process belongs to correct uid
- process name matches
- age of the pidfile

It usually does not include

- check of pid has pidfile open
- check of pid has pidfile locked

because that either isn't portable or requires extra privileges or
isn't reliable. But I've seen this used, e.g. by HA cluster frameworks.

Anything else shouldn't use a pidfile at all but run some kind of
monitor process that just waits for the daemon process to exit.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."