Re: pidfile_lock(3)

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

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.

It could be argued that this is the job of the rc system (or equivalent for 
other OS) and shouldn't be of concern to each program. If this is how others 
think, please say so and I'll toss this patch on the heap and leave things as 
they are.

> > Also, you can only write the pidfile once - subsequent calls to the
> > same file are a non-op so it's useless after forking.
> 
> That the function is idempotent is odd, but does have the advantage of
> discouraging "pre-emptive" use: the daemon must wait until it's done
> daemonizing before writing a pidfile.  That's just as well, ISTM.
> Creating the lockfile early would just leave another misleading marker
> in the traditional pidfile race.

But by using open O_EXLOCK there is no race as my understanding is that it's 
atomic?

> The biggest problem with pidfiles IMO is stale files left over when the
> process terminates abnormally.  That could be remedied with a separate
> daemon, modelled on syslogd, that would create, update and delete
> them.  Modify pidfile(3) to use the daemon, and you solve all three
> problems.

By using flock(2) semantics, the stale file itself is not a problem for the same 
daemon restarting, but you are correct that it is a problem for anyone wanting 
to use the pidfile to work out which process to send a signal to.

Roy