Answers: <p>You could set a fact to be the list of services you need restarted by the handlers: </p>
  
  <pre><code>- name: Tag services to restart
    set_fact:
      services_to_restart:
       - ntp
       - nginx
       - grafana
  </code></pre>
  
  <p>then your handler becomes:</p>
  
  <pre><code>- name: Restart tagged services
    service:
      name: "{{ item }}"
      state: restarted
    loop: "{{ services_to_restart }} | default('nginx')"
  </code></pre>
  
  <p>I suggest using a sane default there in case you send an empty list to the service module.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-27T12:55:49.603Z
Answers: This will restart all the services for each notification
Answers: storm
Answers: CC BY-SA 4.0
Answers: 2018-11-27T12:56:51.573Z
Answers: That's why you only put the ones you want in the variable
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2018-11-27T13:06:54.173Z
Answers: But if a task needs only a restart of ntp, nginx and grafana will be restarted too ..
Answers: storm
Answers: CC BY-SA 4.0
Answers: 2018-11-27T13:24:51.943Z
Answers: @BruceBecker thank you. But this defies the whole purpose of handlers, doesn't it? In order to figure out whether I have to place a particular service name into the list, I'd have to first register a uniquely-named variable and then check whether that task changed anything in a subsequent `set_fact` task. The point of handlers is to make this whole process seamless and low-maintenance. I'd lose all that by using something like your proposed method, even though it may be technically viable.
Answers: 0xC0000022L
Answers: CC BY-SA 4.0
Answers: 2018-11-27T14:26:51.493Z
Answers: ok, good points. The answer by @storm is also more correct, so I suggest you accept that one as the "correct" one.
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2018-11-26T19:31:42.217Z
Answers: 2018-11-26T19:31:42.217Z
Answers: Bruce Becker
Answers: <p>In ansible 2.7 and earlier versions, variables in handlers name are not populated.<br>
  <a href="https://github.com/ansible/ansible/issues/17922" rel="nofollow noreferrer">This bug</a> was reported and a <a href="https://github.com/ansible/ansible/pull/41837" rel="nofollow noreferrer">correction</a> was lately pushed to devel version.</p>
  
  <p>You need to run ansible from devel, and hope they publish this fix in the next release. </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-27T13:05:38.207Z
Answers: 2018-11-27T13:05:38.207Z
Answers: storm
Body: <p>I have an Ansible role which uses handlers to restart services via the <code>systemd</code> module.</p>
  
  <pre><code>- name: restart ntp
    systemd:
      name: ntp
      enabled: yes
      state: restarted
    become: true
  
  - name: restart web server
    systemd:
      name: nginx
      enabled: yes
      state: restarted
    become: true
  
  - name: restart grafana
    systemd:
      name: grafana
      enabled: yes
      state: restarted
    become: true
  </code></pre>
  
  <p>Is there a way so I could parameterize the three separate handlers into something like this?:</p>
  
  <pre><code>- name: restart {{svcname}}
    systemd:
      name: '{{svcname}}'
      enabled: yes
      state: restarted
    become: true
  </code></pre>
  
Tags: <ansible>
Title: Is it possible to consolidate notification handlers when they are very similar?
UserDisplayName: 0xC0000022L
ThreadText: # Is it possible to consolidate notification handlers when they are very similar?
  
  (Asked by: username_0 on 2018-11-26)
  
  I have an Ansible role which uses handlers to restart services via the `systemd` module.
  
  ```
  - name: restart ntp
    systemd:
      name: ntp
      enabled: yes
      state: restarted
    become: true
  
  - name: restart web server
    systemd:
      name: nginx
      enabled: yes
      state: restarted
    become: true
  
  - name: restart grafana
    systemd:
      name: grafana
      enabled: yes
      state: restarted
    become: true
  
  ```
  
  Is there a way so I could parameterize the three separate handlers into something like this?:
  
  ```
  - name: restart {{svcname}}
    systemd:
      name: '{{svcname}}'
      enabled: yes
      state: restarted
    become: true
  
  ```
  
  **Tags:** ansible
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-11-27. Score: 4 | Accepted answer
  
  In ansible 2.7 and earlier versions, variables in handlers name are not populated.  
  [This bug](https://github.com/ansible/ansible/issues/17922) was reported and a [correction](https://github.com/ansible/ansible/pull/41837) was lately pushed to devel version.
  
  You need to run ansible from devel, and hope they publish this fix in the next release.
  
  
  ---
  
  ### Answer by username_1 on 2018-11-26. Score: 1
  
  You could set a fact to be the list of services you need restarted by the handlers:
  
  ```
  - name: Tag services to restart
    set_fact:
      services_to_restart:
       - ntp
       - nginx
       - grafana
  
  ```
  
  then your handler becomes:
  
  ```
  - name: Restart tagged services
    service:
      name: "{{ item }}"
      state: restarted
    loop: "{{ services_to_restart }} | default('nginx')"
  
  ```
  
  I suggest using a sane default there in case you send an empty list to the service module.
  
  > **Comments:**
  > **username_2**: This will restart all the services for each notification  
  > **username_1**: That's why you only put the ones you want in the variable  
  > **username_2**: But if a task needs only a restart of ntp, nginx and grafana will be restarted too ..  
  > **username_0**: @username_1 thank you. But this defies the whole purpose of handlers, doesn't it? In order to figure out whether I have to place a particular service name into the list, I'd have to first register a uniquely-named variable and then check whether that task changed anything in a subsequent `set_fact` task. The point of handlers is to make this whole process seamless and low-maintenance. I'd lose all that by using something like your proposed method, even though it may be technically viable.  
  > **username_1**: ok, good points. The answer by @username_2 is also more correct, so I suggest you accept that one as the "correct" one.  
  
  ---
  
  