Run Immediately an Ansible Handler - Ansible Playbook

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

March 13, 2023

Access the Complete Video Course and Learn Quick Ansible by 200+ Practical Lessons

#ansible #handler #flush #playbook #immediate #devops #code

When do Ansible Handlers run?

By default, handlers run after all the tasks in a particular play have been completed.

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

---
- name: handler demo
  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

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.

$ ansible-playbook -i inventory flush_before.yml

PLAY [handler demo] *********************************************************************

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.

---
- name: handler demo
  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.

% ansible-playbook -i inventory flush.yml    

PLAY [handler demo] *********************************************************************

TASK [Gathering Facts] ******************************************************************
ok: [localhost]

TASK [changed status] *******************************************************************
changed: [localhost]

TASK [flush] ****************************************************************************

RUNNING HANDLER [message 1] *************************************************************
ok: [localhost] => {
    "msg": "message 1"
}

TASK [message 2] ************************************************************************
ok: [localhost] => {
    "msg": "message 2"
}

PLAY RECAP ******************************************************************************
localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0