Comment 9 for bug 933566

On Fri, Feb 17, 2012 at 02:05:02PM -0000, Thomas Hood wrote:

> Using post-stop has the consequence that any error during the resolvconf
> update run in the upstart job causes resolvconf updates to be disabled.
> That is undesirable IMHO.

This is entirely by design. If the errors in the hook scripts should not
cause resolvconf to redisable itself, then resolvconf should be changed to
not return a non-zero exit code here. Otherwise, it's impossible for the
upstart job to distinguish between a fatal error setting up resolvconf
(which should result in the job being marked as "stopped") and an ignorable
hook failure.

We *want* to know if resolvconf has failed to be set up, so that the job's
state reflects reality, and so that when things are broken, 'service
resolvconf start' does the right thing. The unwinding in the post-stop is
an intented side-effect of the job not being considered successfully
started. So the root bug is that resolvconf is returning an error in a case
where it apparently doesn't need to.

Should we adjust resolvconf to not take hook failures into consideration for
its return code?

> Using pre-stop does not have this consequence.

Only because of a bug that prevents the pre-stop script from being run at
all. If and when that bug is fixed, the pre-stop script will have the exact
same effect.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>