Re: pidfile_lock(3)

[Roy Marples <roy%marples.name@localhost>]

On 21/03/2016 00:46, Thor Lancelot Simon wrote:
> 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.

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
difference is that because it's no longer locked it can safely start
where-as with shlock it's possible another process could have the same
PID as the crashed program and falsely think it's locked.

I think that James is on the right track with another daemon cleaning up
pidfiles and handling locking - which solves any NFS problem. If the
daemon (let's call it pidfiled) is unavailable for any reason, then
pidfile_lock(3) can fallback to the existing proposal.
Thinking a little more, the only problem with the pidfiled idea is what
happens with a consumer in a chroot calls pidfile_lock? Is it possible
to get the full real path somehow?

Roy