[Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Robert Edmonds]

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
edmonds at debian.org