On Fri 2017-07-14 16:25:26 -0400, Robert Edmonds wrote: > 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.
I understand what you're saying from the point of view of debian, though it still makes it a little bit strange because then anyone who manually puts DAEMON_OPTS="-p /foo/bar" in /etc/default/unbound has it get overridden. But i was thinking about the issue from upstream -- they have to coordinate their daemon changes with everyone using unbound, and the semantics of running "unbound -c foo.conf" will now change if we change the default, since the default path for the pidfile itself is currently compiled in (if you don't specify pidfile in the config file it'll still create a pidfile, i think). One way to make your approach more feasible (without changing upstream's expected contracts generically) would be to something like (untested): ./configure --with-pidfile= (that is, the empty pidfile). Then anyone on a debian system without a pidfile directive in the .conf just wouldn't get a pidfile (since daemon/unbound.c tests pidfile[0]). if we did that, then adding your proposed implementation to the init script would make sense -- because there'd be no public expectation that -p is something you'd manually supply in DAEMON_OPTS. I guess we're saying that "-p /foo/bar" should take precedence over 'pidfile: "/baz/qux"' in the config file, right? --dkg