Daniel Kahn Gillmor wrote:
> On Fri 2017-07-14 14:19:01 -0400, Robert Edmonds wrote:
> > Hm, that could work (but then we have to carry around "-p" in the
> > service unit forever). I was thinking of a command-line parameter that
> > takes an argument to the pidfile path (like "-p /run/unbound.pid") that
> > takes precedence over the 'pidfile' value from the config file and the
> > compiled in 'pidfile' default value. And then we set the default value
> > for 'pidfile' to "" so that Unbound doesn't make a pidfile by default,
> > and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound.
>
> I figured if we went that way we'd get complaints about changing the
> expected interface/contract with existing users of unbound -- you
> upgrade the main binary on a system that *doesn't* have a
> sensible/modern process manager, and then all of a sudden you don't get
> the pidfile protections by default!
Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in
the sysvinit script unconditionally, something like:
[...]
# Override this variable by editing or creating /etc/default/unbound.
DAEMON_OPTS=""
if [ -f /etc/default/unbound ]; then
. /etc/default/unbound
fi
DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE"
[...]
No changes to the interface/contract. In fact this seems less broken to
me, because we hardcode the path to the pidfile in the sysvinit script.
Currently, if you set 'pidfile' yourself to some other value in the
Unbound config then start-stop-daemon looks in the wrong place for the
pidfile.
--
Robert Edmonds
edmo...@debian.org
