When unbound is maintained by a system manager that can actually keep
track of what daemons are running correctly, a pidfile is an
opportunity for extra failures, rather than a way to avoid failures.
In particular, if unbound terminates roughly, it might leave the
pidfile lying around. Then a subsequent unbound instance will think
that another unbound process is running when it isn't (particularly if
some other stable process happens to have landed on the same process
ID).
So for a system manager that is already capable of keeping track of
whether the daemon is running or not, it would be nice to have the
ability to avoid these extra failure modes by just ignoring pidfiles
entirely.
Since the same unbound config file might need to be used on a
distribution that might use different system managers, being able to
control the use of a pidfile by a command-line argument is probably
the cleanest way to go (see https://bugs.debian.org/867192).
(this is a copy of https://github.com/NLnetLabs/unbound/pull/1)

Hi,
Note that we're still discussing in Debian bug #867192 the best way to support both init systems and I suspect the better approach is to allow configuring the path to the pidfile via the command-line (overriding the compiled-in default and the 'pidfile' config value, if any).