tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pidfile_lock(3)

On 21/03/2016 14:55, Thor Lancelot Simon wrote:
> On Mon, Mar 21, 2016 at 02:30:43PM +0000, Roy Marples wrote:
>>> 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.
>> No, that's exactly what I don't want because if the program crashes the
>> pidfile will persist. It will also exist with my proposal, but the
> But the process won't, so the pidfile can be safely removed after the new
> copy of the daemon confirms that, and you cannot race to create it because
> of the semantics of link(2).

foo starts as PID 10, links /var/foo and writes 10 to it.
foo gets SIGSEGV
bar then starts as PID 10, links /var/bar and writes 10 to it.
foo now wants to restart, but thinks it's already running because it
read /var/foo and PID 10 exists - but it's not foo, it's bar.

> Please do not introduce a daemon just to service pidfile.  And please bear
> in mind that locking over NFS is both unreliably implemented and imperfect
> by design.

How else would you solve your need to work on NFS and my need to lock
and handling crashing programs reliably?


Home | Main Index | Thread Index | Old Index