[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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?
> 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.
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
Main Index |
Thread Index |