On Sat, 19 Mar 2016 23:29:37 +0000 Roy Marples <r...@marples.name> 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? > 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 problems. --jkl
