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/ slanga...@ubuntu.com vor...@debian.org -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/933566 Title: Stopping resolvconf doesn't disable updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/933566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
