By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure::
- name: this will not count as a failure
command: /bin/false
- name: Do not count this as a failure
ansible.builtin.command: /bin/false
ignore_errors: yes
The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It will not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors.
The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors.
Ignoring unreachable host errors
================================
..versionadded:: 2.7
You may ignore task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level::
You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level::
- name: this executes, fails, and the failure is ignored
command: /bin/true
- name: This executes, fails, and the failure is ignored
ansible.builtin.command: /bin/true
ignore_unreachable: yes
- name: this executes, fails, and ends the play for this host
command: /bin/true
- name: This executes, fails, and ends the play for this host
ansible.builtin.command: /bin/true
And at the playbook level::
- hosts: all
ignore_unreachable: yes
tasks:
- name: this executes, fails, and the failure is ignored
command: /bin/true
- name: This executes, fails, and the failure is ignored
ansible.builtin.command: /bin/true
- name: this executes, fails, and ends the play for this host
command: /bin/true
- name: This executes, fails, and ends the play for this host
ansible.builtin.command: /bin/true
ignore_unreachable: no
.._resetting_unreachable:
@ -84,21 +84,21 @@ Ansible lets you define what "failure" means in each task using the ``failed_whe
You may check for failure by searching for a word or phrase in the output of a command::
- name: Fail task when the command error output prints FAILED
You can also combine multiple conditions for failure. This task will fail if both conditions are true::
- name: Check if a file exists in temp and fail task if it does
command: ls /tmp/this_should_not_be_here
ansible.builtin.command: ls /tmp/this_should_not_be_here
register: result
failed_when:
- result.rc == 0
@ -111,7 +111,7 @@ If you want the task to fail when only one condition is satisfied, change the ``
If you have too many conditions to fit neatly into one line, you can split it into a multi-line yaml value with ``>``::
- name: example of many failed_when conditions with OR
shell: "./myBinary"
ansible.builtin.shell: "./myBinary"
register: ret
failed_when: >
("No such file or directory" in ret.stdout) or
@ -127,17 +127,19 @@ Ansible lets you define when a particular task has "changed" a remote node using
tasks:
- shell: /usr/bin/billybass --mode="take me to the river"
- name: Report 'changed' when the return code is not equal to 2
ansible.builtin.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'
- name: This will never report 'changed' status
ansible.builtin.shell: wall 'beep'
changed_when: False
You can also combine multiple conditions to override "changed" result::
- command: /bin/fake_command
- name: Combine multiple conditions to override 'changed' result
ansible.builtin.command: /bin/fake_command
register: result
ignore_errors: True
changed_when:
@ -149,11 +151,11 @@ See :ref:`controlling_what_defines_failure` for more conditional syntax examples
Ensuring success for command and shell
======================================
The :ref:`command <command_module>` and :ref:`shell <shell_module>` modules care about return codes, so if you have a command whose successful exit code is not zero, you may wish to do this::
The :ref:`command <command_module>` and :ref:`shell <shell_module>` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this::