2013-09-29 23:10:28 +00:00
|
|
|
Error Handling In Playbooks
|
|
|
|
===========================
|
2012-05-13 15:00:02 +00:00
|
|
|
|
2013-12-26 19:32:01 +00:00
|
|
|
.. contents:: Topics
|
|
|
|
|
2013-10-03 02:03:15 +00:00
|
|
|
Ansible normally has defaults that make sure to check the return codes of commands and modules and
|
|
|
|
it fails fast -- forcing an error to be dealt with unless you decide otherwise.
|
2013-11-16 22:01:26 +00:00
|
|
|
|
2013-09-29 20:47:34 +00:00
|
|
|
Sometimes a command that returns 0 isn't an error. Sometimes a command might not always
|
|
|
|
need to report that it 'changed' the remote system. This section describes how to change
|
|
|
|
the default behavior of Ansible for certain tasks so output and error handling behavior is
|
|
|
|
as desired.
|
2012-08-01 02:19:04 +00:00
|
|
|
|
2013-10-04 22:34:39 +00:00
|
|
|
.. _ignoring_failed_commands:
|
|
|
|
|
2012-08-03 02:08:00 +00:00
|
|
|
Ignoring Failed Commands
|
|
|
|
````````````````````````
|
|
|
|
|
2012-10-16 22:15:41 +00:00
|
|
|
.. versionadded:: 0.6
|
2012-08-07 02:32:40 +00:00
|
|
|
|
|
|
|
Generally playbooks will stop executing any more steps on a host that
|
|
|
|
has a failure. Sometimes, though, you want to continue on. To do so,
|
|
|
|
write a task that looks like this::
|
2012-08-03 02:08:00 +00:00
|
|
|
|
|
|
|
- name: this will not be counted as a failure
|
2013-07-15 17:50:48 +00:00
|
|
|
command: /bin/false
|
2012-12-14 10:56:53 +00:00
|
|
|
ignore_errors: yes
|
2012-08-03 02:08:00 +00:00
|
|
|
|
2014-02-15 19:05:42 +00:00
|
|
|
Note that the above system only governs the failure of the particular task, so if you have an undefined
|
|
|
|
variable used, it will still raise an error that users will need to address.
|
|
|
|
|
2015-04-04 20:37:14 +00:00
|
|
|
.. _handlers_and_failure:
|
|
|
|
|
|
|
|
Handlers and Failure
|
|
|
|
````````````````````
|
|
|
|
|
|
|
|
.. versionadded:: 1.9.1
|
|
|
|
|
|
|
|
When a task fails on a host, handlers which were previously notified
|
|
|
|
will *not* be run on that host. This can lead to cases where an unrelated failure
|
|
|
|
can leave a host in an unexpected state. For example, a task could update
|
|
|
|
a configuration file and notify a handler to restart some service. If a
|
|
|
|
task later on in the same play fails, the service will not be restarted despite
|
|
|
|
the configuration change.
|
|
|
|
|
|
|
|
You can change this behavior with the ``--force-handlers`` command-line option,
|
|
|
|
or by including ``force_handlers: True`` in a play, or ``force_handlers = True``
|
|
|
|
in ansible.cfg. When handlers are forced, they will run when notified even
|
|
|
|
if a task fails on that host. (Note that certain errors could still prevent
|
|
|
|
the handler from running, such as a host becoming unreachable.)
|
|
|
|
|
2013-10-12 15:20:56 +00:00
|
|
|
.. _controlling_what_defines_failure:
|
2013-10-12 14:51:32 +00:00
|
|
|
|
|
|
|
Controlling What Defines Failure
|
|
|
|
````````````````````````````````
|
|
|
|
|
|
|
|
.. versionadded:: 1.4
|
|
|
|
|
2013-10-17 14:00:58 +00:00
|
|
|
Suppose the error code of a command is meaningless and to tell if there
|
2013-10-12 14:51:32 +00:00
|
|
|
is a failure what really matters is the output of the command, for instance
|
|
|
|
if the string "FAILED" is in the output.
|
|
|
|
|
|
|
|
Ansible in 1.4 and later provides a way to specify this behavior as follows::
|
|
|
|
|
|
|
|
- name: this command prints FAILED when it fails
|
|
|
|
command: /usr/bin/example-command -x -y -z
|
|
|
|
register: command_result
|
|
|
|
failed_when: "'FAILED' in command_result.stderr"
|
|
|
|
|
|
|
|
In previous version of Ansible, this can be still be accomplished as follows::
|
|
|
|
|
|
|
|
- name: this command prints FAILED when it fails
|
|
|
|
command: /usr/bin/example-command -x -y -z
|
|
|
|
register: command_result
|
|
|
|
ignore_errors: True
|
|
|
|
|
|
|
|
- name: fail the play if the previous command did not succeed
|
|
|
|
fail: msg="the command failed"
|
|
|
|
when: "'FAILED' in command_result.stderr"
|
|
|
|
|
2013-10-04 22:34:39 +00:00
|
|
|
.. _override_the_changed_result:
|
|
|
|
|
2013-09-29 23:10:28 +00:00
|
|
|
Overriding The Changed Result
|
|
|
|
`````````````````````````````
|
2013-07-14 19:43:10 +00:00
|
|
|
|
|
|
|
.. versionadded:: 1.3
|
|
|
|
|
2013-07-21 14:48:22 +00:00
|
|
|
When a shell/command or other module runs it will typically report
|
2013-07-23 22:49:27 +00:00
|
|
|
"changed" status based on whether it thinks it affected machine state.
|
2013-07-21 14:48:22 +00:00
|
|
|
|
|
|
|
Sometimes you will know, based on the return code
|
|
|
|
or output that it did not make any changes, and wish to override
|
|
|
|
the "changed" result such that it does not appear in report output or
|
|
|
|
does not cause handlers to fire::
|
2013-07-14 19:43:10 +00:00
|
|
|
|
|
|
|
tasks:
|
2013-07-21 14:48:22 +00:00
|
|
|
|
|
|
|
- shell: /usr/bin/billybass --mode="take me to the river"
|
|
|
|
register: bass_result
|
|
|
|
changed_when: "bass_result.rc != 2"
|
|
|
|
|
|
|
|
# this will never report 'changed' status
|
|
|
|
- shell: wall 'beep'
|
2013-10-18 18:13:13 +00:00
|
|
|
changed_when: False
|
2013-07-14 19:43:10 +00:00
|
|
|
|
2012-05-13 15:00:02 +00:00
|
|
|
|
2013-10-05 16:31:16 +00:00
|
|
|
.. seealso::
|
|
|
|
|
|
|
|
:doc:`playbooks`
|
|
|
|
An introduction to playbooks
|
|
|
|
:doc:`playbooks_best_practices`
|
|
|
|
Best practices in playbooks
|
|
|
|
:doc:`playbooks_conditionals`
|
|
|
|
Conditional statements in playbooks
|
|
|
|
:doc:`playbooks_variables`
|
|
|
|
All about variables
|
|
|
|
`User Mailing List <http://groups.google.com/group/ansible-devel>`_
|
|
|
|
Have a question? Stop by the google group!
|
|
|
|
`irc.freenode.net <http://irc.freenode.net>`_
|
|
|
|
#ansible IRC chat channel
|
|
|
|
|
2012-05-13 15:00:02 +00:00
|
|
|
|