AnsiblePilot — Master Ansible Automation

AnsiblePilot is the leading resource for learning Ansible automation, DevOps, and infrastructure as code. Browse over 1,100 tutorials covering Ansible modules, playbooks, roles, collections, and real-world examples. Whether you are a beginner or an experienced engineer, our step-by-step guides help you automate Linux, Windows, cloud, containers, and network infrastructure.

Popular Topics

About Luca Berton

Luca Berton is an Ansible automation expert, author of "Ansible for VMware by Examples" and "Ansible for Kubernetes by Example" published by Apress, and creator of the Ansible Pilot YouTube channel. He shares practical automation knowledge through tutorials, books, and video courses to help IT professionals and DevOps engineers master infrastructure automation.

Ansible Handlers Explained: How to Use and Flush Handlers — Video Tutorial

How to flush the execution of an Ansible handler after the notification task using the ansible.builtin.meta module.

Watch Video

Watch "Ansible Handlers Explained: How to Use and Flush Handlers" on YouTube

What You'll Learn

Full Tutorial Content

When do Ansible Handlers run? > By default, handlers run after all the tasks in a particular play have been completed. Links - https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#controlling-when-handlers-run Demo Let's jump into a real-life example of how to run an Ansible Handler immediately. First of all, we need a task changed status. The simplest Ansible module returning a "changed" status is Ansible `command` module with a Linux command, like "uptime". Let's suppose we would like to execute a handler immediately after the changed status and not wait for the next task using the `ansible.builtin.meta` module. Initial Playbook - flush_before.yml ```yaml --- - name: handler Playbook hosts: all tasks: - name: changed status ansible.builtin.command: "uptime" notify: message 1 - name: message 2 ansible.builtin.debug: msg: message 2 handlers: - name: message 1 ansible.builtin.debug: msg: message 1 ``` inventory ```ini localhost ansible_connection=local ``` Initial Execution As you can notice the `message 1` handler is executed AFTER the last task (`message 2`) of the Play being executed. ```bash $ ansible-playbook -i inventory flush_before.yml PLAY [handler Playbook] ********************************************************************* TASK [Gathering Facts] ****************************************************************** ok: [localhost] TASK [changed status] ******************************************************************* changed: [localhost] TASK [message 2] ************************************************************************ ok: [localhost] => { "msg": "message 2" } RUNNING HANDLER [message 1] ************************************************************* ok: [localhost] => { "msg": "message 1" } PLAY RECAP ****************************************************************************** localhost : ok=4 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` Modified Playbook Let's add the `ansible.builtin.meta` Ansible module after the first task. ```yaml --- - name: handler Playbook hosts: all tasks: - name: changed status ansible.builtin.command: "uptime" notify: message 1 - name: flush ansible.builtin.meta: flush_handlers - name: message 2 ansible.builtin.debug: msg: message 2 handlers: - name: message 1 ansible.builtin.debug: msg: message 1 ``` Modified Execution As you can notice the `message 1` handler is executed BEFORE the last task (`message 2`) of the Play being executed. ```bash % ansible-playbook -i inventory flush.yml PLAY [handler Playbook] ********************************************************************* TASK [Gathering Facts] ****************************************************************** ok: [localhost] TASK [changed status] ***********************************************

About This Tutorial

Read the full written article: Ansible Handlers Explained: How to Use and Flush Handlers

Topics Covered

Related Video Tutorials