<p>In 2.5+ (well after the question), there is the debugger which covers most of this:
<a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_debugger.html" rel="nofollow noreferrer">https://docs.ansible.com/ansible/latest/user_guide/playbooks_debugger.html</a></p>

<p>As for one at a time, using "--forks 1" only connects to one system at a time if you want to do it ad-hoc and not every time.</p>

CC BY-SA 4.0
2019-04-04T20:30:32.943Z
2019-04-04T20:30:32.943Z
Matt Piechota
<p>Your playbook will stop when a failure occurs and you're using <code>serial: 1</code> according to the <a href="http://docs.ansible.com/ansible/playbooks_delegation.html#maximum-failure-percentage" rel="noreferrer">documentation</a>.</p>

<blockquote>
  <p>By default, Ansible will continue executing actions as long as there are hosts in the group that have not yet failed. </p>
</blockquote>

<p>That said there seems to be some confusion in the community over the default behavior, and it seems to have changed--or been buggy--somewhere between 1.8 and 2.1.</p>

<p>So, if <code>serial: 1</code> doesn't suffice, use this additional setting:</p>

<p><code>max_failure_percentage: 0</code></p>

<blockquote>
  <p>In some situations, such as with the rolling updates described above, it may be desirable to abort the play when a certain threshold of failures have been reached. To achieve this, as of version 1.3 you can set a maximum failure percentage...</p>
</blockquote>

<p>==</p>

<p>As for retrying your playbook, you should be seeing a failure message like this:</p>

<p><code>to retry, use: --limit @/home/user/site.retry</code></p>

<p>Use that <code>--limit</code> flag and on your next execution of <code>ansible-playbook</code> and it will continue from where it failed.</p>

<p>Retry files will be created unless you've set <code>retry_files_enabled = False</code> in your configuration.</p>

<p>Alternatively, <code>--start-at-task</code> may also work.</p>

<p>Sources:</p>

<p><a href="https://github.com/ansible/ansible/issues/1663" rel="noreferrer">https://github.com/ansible/ansible/issues/1663</a></p>

<p><a href="https://github.com/ansible/ansible/issues/16241" rel="noreferrer">https://github.com/ansible/ansible/issues/16241</a></p>

<p><a href="http://docs.ansible.com/ansible/playbooks_delegation.html#rolling-update-batch-size" rel="noreferrer">http://docs.ansible.com/ansible/playbooks_delegation.html#rolling-update-batch-size</a></p>

<p><a href="http://docs.ansible.com/ansible/playbooks_delegation.html#maximum-failure-percentage" rel="noreferrer">http://docs.ansible.com/ansible/playbooks_delegation.html#maximum-failure-percentage</a></p>

<p><a href="http://docs.ansible.com/ansible/intro_configuration.html#retry-files-enabled" rel="noreferrer">http://docs.ansible.com/ansible/intro_configuration.html#retry-files-enabled</a></p>

<p><a href="http://docs.ansible.com/ansible/playbooks_startnstep.html#start-at-task" rel="noreferrer">http://docs.ansible.com/ansible/playbooks_startnstep.html#start-at-task</a></p>

CC BY-SA 3.0
2017-03-02T21:04:58.973Z
If anyone has a better sense of what happened to the change/bug in 1.9 and 2.0 please let me know and I'll update this answer.
Woodland
CC BY-SA 3.0
2017-03-02T21:16:51.903Z
Yeah, I know that ansible 2.0 will continue to run on other hosts if it gets failures on one of 'em.   I guess I didn't think it would have different behavior if I ran serial:1.  Is that what you're saying?
Peter Turner
CC BY-SA 3.0
2017-03-02T21:20:06.967Z
That's correct, serial: 1 should have that behavior, and if it doesn't (because ??) add max_failure_percentage: 0, too. I'd also suggest upgrading Ansible as 2.0 had a *lot* of bugs.
Woodland
CC BY-SA 3.0
2017-03-02T21:21:20.637Z
So many bugs, in fact, that you are missing the .retry files in 2.0! https://github.com/ansible/ansible/issues/13944
Woodland
CC BY-SA 3.0
2017-03-02T21:41:21.690Z
Heh, so I'm not the only one who is constantly patching the source.  That's good to know.
Peter Turner
CC BY-SA 3.0
2017-03-02T21:03:40.997Z
2017-03-02T22:10:54.557Z
2017-03-02T22:10:54.557Z
Woodland
<p>I've got an Ansible playbook where I want to update a number of flaky devices in sequence. I can use <code>serial:1</code>, but I want to stop the playbook altogether if I get a failure so I can fix it before proceeding instead of accumulating errors.</p>

<p>I'd also like to restart the playbook at the same host I stopped on.  Currently using Ansible v2.0, but can also switch to a newer version if that sort of a feature is only available in newer versions. </p>

<ansible>
How do I run ansible on one host at a time and break on a failure
Peter Turner
# How do I run ansible on one host at a time and break on a failure

(Asked by: username_0 on 2017-03-02)

I've got an Ansible playbook where I want to update a number of flaky devices in sequence. I can use `serial:1`, but I want to stop the playbook altogether if I get a failure so I can fix it before proceeding instead of accumulating errors.

I'd also like to restart the playbook at the same host I stopped on. Currently using Ansible v2.0, but can also switch to a newer version if that sort of a feature is only available in newer versions.

**Tags:** ansible


---

## 2 answers

### Answer by username_2 on 2017-03-02. Score: 16

Your playbook will stop when a failure occurs and you're using `serial: 1` according to the [documentation](http://docs.ansible.com/ansible/playbooks_delegation.html#maximum-failure-percentage).

> By default, Ansible will continue executing actions as long as there are hosts in the group that have not yet failed.

That said there seems to be some confusion in the community over the default behavior, and it seems to have changed--or been buggy--somewhere between 1.8 and 2.1.

So, if `serial: 1` doesn't suffice, use this additional setting:

`max_failure_percentage: 0`

> In some situations, such as with the rolling updates described above, it may be desirable to abort the play when a certain threshold of failures have been reached. To achieve this, as of version 1.3 you can set a maximum failure percentage...

==

As for retrying your playbook, you should be seeing a failure message like this:

`to retry, use: --limit @/home/user/site.retry`

Use that `--limit` flag and on your next execution of `ansible-playbook` and it will continue from where it failed.

Retry files will be created unless you've set `retry_files_enabled = False` in your configuration.

Alternatively, `--start-at-task` may also work.

Sources:

<https://github.com/ansible/ansible/issues/1663>

<https://github.com/ansible/ansible/issues/16241>

<http://docs.ansible.com/ansible/playbooks_delegation.html#rolling-update-batch-size>

<http://docs.ansible.com/ansible/playbooks_delegation.html#maximum-failure-percentage>

<http://docs.ansible.com/ansible/intro_configuration.html#retry-files-enabled>

<http://docs.ansible.com/ansible/playbooks_startnstep.html#start-at-task>

> **Comments:**
> **username_2**: If anyone has a better sense of what happened to the change/bug in 1.9 and 2.0 please let me know and I'll update this answer.  
> **username_0**: Yeah, I know that ansible 2.0 will continue to run on other hosts if it gets failures on one of 'em.   I guess I didn't think it would have different behavior if I ran serial:1.  Is that what you're saying?  
> **username_2**: That's correct, serial: 1 should have that behavior, and if it doesn't (because ??) add max_failure_percentage: 0, too. I'd also suggest upgrading Ansible as 2.0 had a *lot* of bugs.  
> **username_2**: So many bugs, in fact, that you are missing the .retry files in 2.0! https://github.com/ansible/ansible/issues/13944  
> **username_0**: Heh, so I'm not the only one who is constantly patching the source.  That's good to know.  

---

### Answer by username_1 on 2019-04-04. Score: 2

In 2.5+ (well after the question), there is the debugger which covers most of this:
<https://docs.ansible.com/ansible/latest/user_guide/playbooks_debugger.html>

As for one at a time, using "--forks 1" only connects to one system at a time if you want to do it ad-hoc and not every time.


---

