[Resolvconf-devel] Bug#563386: Bug#563386: resolvconf: Error: /etc/resolvconf/run/interface is not a directory

[resolvconferrormesg.to.peejay at spamgourmet.com]

> Here's an idea for eliminating the race.  Ship /sbin/resolvconf without
> x permission and have the postinst set the x permission only once
> resolvconf is ready for use.  (Dnsmasq and other clients generally test
> for executable /sbin/resolvconf before calling it.)

The wishlist item in 213591 (using locks) may also be an alternative.

But neither locks, nor a +x check is likely practical for all clients, so
it is likely to fail as a full fix for some odd cases.

Eg: it currently doesn't get around the problem case of if dnsmasq is
installed first, and then later (before a reboot) resolvconf is installed
next.

Should resolvconf really worry about these? If it should, then why not
just restart dnsmasq after resolvconf is installed? (I am not yet familiar
enough with debian packaging to know if a postinst script dependency check
could (or should) do that).

Maybe just have a warning that services like dnsmasq that rely on
resolvconf may need a restart. (I seem to remember similar warnings for
other packages that involved a restart for services, so it may be a debian
best practice). It would certainly keep things simple, which is good.

regards
PJ

Addendum: snippet from #debian-devel where I discussed above:

<peej> package A installs stuff which requires package B to restart. Is
that a job for postinst scripts?
<Yoe> peej: I'd say that's a job for a trigger by package B
<peej> I am unfamiliar with debian packaging. Can you explain what you
mean by trigger?
<jcristau> peej: /usr/share/doc/dpkg/triggers.txt.gz
<peej> cool.
<cortana> or not even triggers. if package b has a daemon that needs to
reload, it should just watch the directory containing the files and reload
when new ones appear
<Yoe> cortana: yes, but then not all daemons do that
<cortana> yeah. if the maintainer patches the daemon then other distros
can benefit too :)
<Yoe> and a trigger may be easier to implement
<ron> and you get triple NIH points for a debian specific solution
<peej> actually, it concerns
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563386, where the
suggested +x solution doesn't solve the edge case of dnsmasq installed
first, then, before a reboot is done, resolvconf is installed next.
<peej> (package A is therefore resolvconf here, and B dnsmasq that needs
the restart)
<ron> doesn't resolvconf let you install hooks to do that?
<peej> ron, do you mean hooks to specify a restart for all possible
services that depend on resolvconf ?
<ron> the +x "solution" would seem to violate all manner of good taste
conventions
<ron> well I see /etc/resolvconf/update-libc.d with some scripts in it ..