this is a bug…
TASK: [pdns-recursor | recursor.conf file] ************************************
changed: [10.56.252.12]
ERROR: change handler (restart pdns-recursor) is not defined
… so my issue was that the handler wasn’t defined (typo). So now it has a new file, and the daemon NEEDS to be restarted , but it isn’t.
Now, when I run ansible again, it does NOT restart the daemon, because the template is already updated.
The solution here would obviously need to restart the daemon and properly run the handler.
I think the fix is to revert the ‘template’ so that the previous file was used.
Don’t see how this is a bug. Can you elaborate.
Tried --force-handlers ?
No, you actually use that after.
If you had a failure and you needed a handler to run on the next run because something should have triggered but did not, you can use that flag.
The retry suggestion has been made before.
Interesting. Nice discussion.
I think one issue is that there would be no easy way to revert tasks that fail without some type of API that instrumented changes. Either that or have the tasks run in some sort of container that logged changes. But of course you’re not sure what type of changes to expect. It could be a sysctl, FS changes, API call, etc. How do you reliably roll those back?
So I guess the solution is to just be careful and know what your scripts are doing. And maybe in the future tasks could implement a rollback API for when they fail but of course this might not be reliably supported everywhere.
“I am afraid this is not correct. I am testing it now with 1.8.2 and I can assure you that ‘–force-handlers’ will not trigger a handler if that handler has not been notified by a task.”
Can you please paste a minimal playbook that shows this as well as your CLI invocation?
Thanks!