CODEWITHSUNDEEP
handleransible
Nova
Nova

Reputation: 1270

Ansible handler does not run multiple handler tasks

We have one Ansible role that needs to run three tasks in the handlers/main.yml task file, but it only runs the first task. How do I force it to run the other two tasks? I do have the ignore flag on for if the first task fails.

The tasks/main.yml file looks like:

- name: openfire | Copy plugins into openfire/plugins
  copy: src={{ srcdir }}/xmpp/{{ item }} dest=${bindir}/openfire/plugins/{{ item }}
  with_items:
   - x.jar
   - y.jar
  sudo: yes
  sudo_user: ${tomcat_user}
  notify: restart openfire

- name: openfire | Copy jars into openfire/lib
  copy: src={{ srcdir }}/xmpp/{{ item }} dest=${bindir}/openfire/lib/{{ item }}
  with_items:
   - a.jar
   - b.jar
  sudo: yes
  sudo_user: ${tomcat_user}
  notify: restart openfire

The handlers/main.yml file looks like:

- name: restart openfire
  service: name=openfire state=stopped
  ignore_errors: true
  sudo: yes

- name: restart openfire
  file: path=/var/run/openfire.pid state=absent
  sudo: yes

- name: restart openfire
  service: name=openfire state=restarted enabled=yes
  sudo: yes

Only the first handler task (shut down openfire) runs.

Upvotes: 22

Views: 35911

Answers (4)

Xiong Chiamiov
Xiong Chiamiov

Reputation: 13694

As of Ansible 2.2, you can now notify multiple handlers at the same time using the listen directive:

- name: stop openfire
  listen: restart openfire
  service: name=openfire state=stopped
  ignore_errors: true
  sudo: yes

- name: remove openfire pid file
  listen: restart openfire
  file: path=/var/run/openfire.pid state=absent
  sudo: yes

- name: restart openfire
  listen: restart openfire
  service: name=openfire state=restarted enabled=yes
  sudo: yes

Upvotes: 23

iTake
iTake

Reputation: 4190

Its possible for handler to call another notify. Multiple notify calls are also allowed:

---
- name: restart something
  command: shutdown.sh 
  notify:
    - wait for stop
    - start something
    - wait for start

- name: wait for stop
  wait_for: port={{port}} state=stopped

- name: start something
  command: startup.sh

- name: wait for start
  wait_for: port={{port}} state=started

Upvotes: 31

José L. Patiño
José L. Patiño

Reputation: 3809

Maybe it is too late, since your post is from January, but... why are you naming identically all the different handlers? It is supposed for the handlers to be called in the tasks by their name, so maybe you need to name them differently. Try to change the handlers file to something like this:

- name: stop openfire
  service: name=openfire state=stopped
  ignore_errors: true
  sudo: yes

- name: remove openfire pid
  file: path=/var/run/openfire.pid state=absent
  sudo: yes

- name: restart openfire
  service: name=openfire state=restarted enabled=yes
  sudo: yes

Anyway, I agree with Mxx in the point that this handlers file is quite strange. It should be enough with a state=restarted.

Upvotes: 9

geerlingguy
geerlingguy

Reputation: 4802

The way the example code above is using notify in Ansible isn't officially supported, so I'm not surprised it's not working (and would be surprised if it ever were really working). In your particular case, using one task in your playbook, or a handler that simply uses state=restarted to restart the service, would be a better option:

- service: name=openfire state=restarted enabled=yes

However, if you do need to have multiple handlers run as a result of one operation, the best way to do it would be to notify each separate command in a chain. Note that this is almost always indicative of a deeper problem... but every once in a while, I've had to notify another handler after a certain handler completed, like so:

# Inside handlers/main.yml:
- name: import database
  mysql_db: name=database state=import target=/path/to/dump.sql
  notify: run shell script

- name: run shell script
  shell: /path/to/some/shell/script.sh

This should be pretty rare, but I wouldn't think it's too bad an option for certain scenarios (in my case, I had to import a database dump, then run a shell script after that was complete, and the best way to make that operation idempotent was to notify the import database handler instead of try doing the import directly in my playbook).

Upvotes: 8

Related Questions