I've experienced two similar issues with handlers not running: - a misbehaving host hangs forever during a task, forcing you to kill the playbook run, so no handlers for anyone are ever notified - a host's task succeeds but its handler times out (e.g. due to flaky connection), so that handler is never run
Perhaps the queued up handlers might fix the first one, and the --force-handlers (with an optional handler filter?) would be useful for the second. Since the handlers are not idempotent and I have to kind of baby them anyway, I have resorted to converting them to tasks and either running them unconditionally, or having them depend on something more reliable as in a Makefile-like timestamp dependency. This isn't ideal, but it beats getting out of sync. Maybe there is no solution that fits within the design goals of ansible? On Sunday, December 1, 2013 7:56:27 AM UTC-6, Michael DeHaan wrote: > > "Okay, what about making ansible run any queued up handlers just before > exiting, even if it exits due to an error condition in a playbook?" > > Yep, that's what I was thinking of this morning. > > I still think we *may* want that behavior to be flag/setting controlled. > > > > On Sat, Nov 30, 2013 at 1:52 PM, Anand Buddhdev <arh...@gmail.com<javascript:> > > wrote: > >> Okay, what about making ansible run any queued up handlers just before >> exiting, even if it exits due to an error condition in a playbook? >> >> Anand >> >> On Saturday, 30 November 2013 18:04:55 UTC+1, Michael DeHaan wrote: >> >> Not sure that's an option that fits all use cases. >>> >>> -- Michael >>> >>> On Nov 30, 2013, at 11:40 AM, Anand Buddhdev <arh...@gmail.com> wrote: >>> >>> On Friday, 29 November 2013 17:14:37 UTC+1, Michael DeHaan wrote: >>> >>> Hi Michael, >>> >>> Yep, this is a thing, there's no way to force running all of the >>>> handlers. >>>> >>>> There's a feature request open for something like --force-handlers that >>>> would be super easy to add. >>>> >>>> But would you generically want to run all of them in every case? Might >>>> not work for everyone. Might though. >>>> >>> >>> I have also run into this issue, where an error in a playbook will cause >>> ansible to stop, and fail to run any requested handlers, which can leave a >>> daemon running with an old configuration, for example. This kind of breaks >>> ansible's idempotent feature. Instead of --force-handlers, what about if >>> ansible were to maintain a persistent cache of requested handlers (in a >>> file, for example) and apply them at the next run? >>> >>> In our case, we use ansible in local mode, so we can't always see if a >>> playbook run failed or not, and if ansible kept a cache of handlers, and >>> deleted it only when they were applied, it would solve this problem without >>> requiring a --force-handlers option. >>> >>> Regards, >>> >>> Anand >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ansible-proje...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ansible-proje...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Michael DeHaan <mic...@ansibleworks.com <javascript:>> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
