ansible/docsite/rst/playbooks_error_handling.rst

123 lines
4.1 KiB
ReStructuredText
Raw Normal View History

2013-09-29 23:10:28 +00:00
Error Handling In Playbooks
===========================
2012-05-13 15:00:02 +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
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.
.. _ignoring_failed_commands:
Ignoring Failed Commands
````````````````````````
2012-10-16 22:15:41 +00:00
.. versionadded:: 0.6
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::
- name: this will not be counted as a failure
2013-07-15 17:50:48 +00:00
command: /bin/false
ignore_errors: yes
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.
.. _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"
.. _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
.. 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