Comment 10 for bug 933566

Upstart sees resolvconf as a persistent job and keeps track of its state, running or stopped. One significance of this is that Upstart won't start resolvconf if it is already "running" or stop it if it is already "stopped".

The part of resolvconf that conforms to this model is the enabling and disabling of updates. We want to make use of this at shutdown time.

So long as resolvconf is treated as an Upstart job there should be a one-to-one correlation:

    resolvconf updates enabled == resolvconf Upstart job running
    resolvconf updates disabled == resolvconf Upstart job stopped

In order to ensure this, "resolvconf --enable-updates" should return a nonzero error code if and only if it failed to enable updates, i.e., failed to create the /run/resolvconf/enable-updates flag file.

Likewise "resolvconf --disable-updates" should return a nonzero error code if and only if it failed to disable updates. Fortunately it already does so.

Steve wrote in #9:
> Should we adjust resolvconf to not take hook failures into consideration for its return code?

The smallest modification would be to make the suggested change only to the enable-updates case, as follows.

$ diff -u resolvconf_ORIG resolvconf
--- resolvconf_ORIG 2012-02-19 16:49:46.725254960 +0100
+++ resolvconf 2012-02-19 16:51:39.277257572 +0100
@@ -113,9 +113,9 @@
  fi
  ;;
   --enable-updates)
- : >| "$ENABLE_UPDATES_FLAGFILE"
+ : >| "$ENABLE_UPDATES_FLAGFILE" || exit 1
  if [ -e "$POSTPONED_UPDATE_FLAGFILE" ] ; then
- update_and_exit -u
+ (update_and_exit -u) || :
  fi
  exit 0
  ;;

With this, other callers of resolvconf won't see any change in exit code semantics.