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?
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
Loaded: loaded (/lib/systemd/system/tor@.service; enabled)
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.
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?
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.
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?)
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.