# bug in service module when enabling multiple systemd (multi-instance) services?

**URL:** <https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903>\
**Category:** Ansible Project\
**Created:** [April 3, 2015, 9:56pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903 "2015-04-03T21:56:46Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nusenu1](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@Nusenu1](https://forum.ansible.com/u/Nusenu1)\
**Post date:** [April 3, 2015, 9:56pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/1 "2015-04-03T21:56:46Z")

</div>

Hi,

I'm enabling multiple instances of a service via:

service: name=tor@{{ item }}.service enabled=yes state=started  
&nbsp;&nbsp;with\_items:  
&nbsp;&nbsp;- foo  
&nbsp;&nbsp;- bar

Both services get started properly but only the first gets enabled  
persistently. There is only one link created under:  
/etc/systemd/system/multi-user.target.wants/

Can anyone confirm this bug or am I missing something?

thanks,  
Nusenu

ansible version: 1.8.4  
target: debian jessie (systemd version: 215)

Background about systemd instances:  
[http://0pointer.de/blog/projects/instances.html](http://0pointer.de/blog/projects/instances.html)

---

<div class="post-metadata">

**Author:** ![Nusenu1](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@Nusenu1](https://forum.ansible.com/u/Nusenu1)\
**Post date:** [April 3, 2015, 10:46pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/2 "2015-04-03T22:46:24Z")

</div>

> Can anyone confirm this bug or am I missing something?

Ok, the problem seems to be that ansible probably runs status on the  
particular service before enabling it (to avoid unnecessary systemctl  
enable commands?).

systemctl output for the \*not\* enabled service looks like this:

systemctl status tor@bar.service  
��tor@bar.service - Anonymizing overlay network for TCP  
&nbsp;&nbsp;&nbsp;Loaded: loaded (/lib/systemd/system/tor@.service; enabled)  
&nbsp;&nbsp;&nbsp;Active: inactive (dead)

So once a particular multi-instance unit file has been enabled at  
least once, systemctl will always return enabled - no matter what  
instance we ask for. So now I'm not sure whether this is the way how  
systemctl is supposed to behave or if that is an upstream bug.

I'll ask on systemd-devel..

---

<div class="post-metadata">

**Author:** ![Nusenu1](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@Nusenu1](https://forum.ansible.com/u/Nusenu1)\
**Post date:** [April 3, 2015, 11:42pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/3 "2015-04-03T23:42:32Z")

</div>

Nusenu:

> Ok, the problem seems to be that ansible probably runs status on  
> the particular service before enabling it (to avoid unnecessary  
> systemctl enable commands?).

actually the service module executes [1]:  
systemctl is-enabled tor@bar.service

which should be fine.

Since there is no get\_systemd\_service\_enabled() in my local service.py  
(ansible 1.8.4) I guess this has been fixed in ansible \>1.8.4?

One more reason to upgrade to 1.9..

[1]  
[https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L486](https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L486)

---

<div class="post-metadata">

**Author:** ![Nusenu1](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@Nusenu1](https://forum.ansible.com/u/Nusenu1)\
**Post date:** [April 4, 2015, 6:32am UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/4 "2015-04-04T06:32:24Z")

</div>

> Since there is no get\_systemd\_service\_enabled() in my local  
> service.py (ansible 1.8.4) I guess this has been fixed in ansible  
> \>1.8.4?
> 
> One more reason to upgrade to 1.9..

Indeed, works fine with ansible v1.9.

---

<div class="post-metadata">

**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\
**Post date:** [April 6, 2015, 3:41pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/5 "2015-04-06T15:41:13Z")

</div>

Hi, yes definitely test this out with either devel or 1.9.x to see if the issue has been fixed (I know there were some fixes in service regarding systemd). If not, definitely let us know or open a github issue.

Thanks!

---

<div class="post-metadata">

**Author:** ![Nusenu1](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@Nusenu1](https://forum.ansible.com/u/Nusenu1)\
**Post date:** [April 6, 2015, 3:47pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/6 "2015-04-06T15:47:46Z")

</div>

Hi,

> Hi, yes definitely test this out with either devel or 1.9.x to see  
> if the issue has been fixed (I know there were some fixes in  
> service regarding systemd). If not, definitely let us know or open  
> a github issue.

As I wrote [1] on 2015-04-04 6:32 +0000 it works fine with 1.9.0.1-1.  
(maybe I shouldn't have changed the subject?)

[1]  
[https://groups.google.com/forum/#!msg/ansible-project/OmJhOGmymH8/lxOQBDkHWWgJ](https://groups.google.com/forum/#!msg/ansible-project/OmJhOGmymH8/lxOQBDkHWWgJ)

---

<div class="post-metadata">

**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\
**Post date:** [April 6, 2015, 3:50pm UTC](https://forum.ansible.com/t/bug-in-service-module-when-enabling-multiple-systemd-multi-instance-services/17903/7 "2015-04-06T15:50:47Z")

</div>

My apologies, I hadn’t gotten to that one in the ML yet. Groups put that in a new thread instead of in-line with this one, so definitely keep the subject for on-topic replies.

Thanks!
