Daniel Kahn Gillmor wrote: > 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.
I guess we could override the variable like: DAEMON_OPTS="-p ... $DAEMON_OPTS" so that if DAEMON_OPTS="-p ..." appears in /etc/default/unbound, the setting in /etc/default/unbound would take precedence. But if you're trying to override the pidfile path, this has never actually worked without editing the sysvinit script, so I don't care too much about this use case. > 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? Yeah, exactly. -- Robert Edmonds edmo...@debian.org