systemd and service modules don't check is-enabled stdout values, causing false positives

[skylerbunny]

ISSUE TYPE

• Bug Report

COMPONENT NAME

systemd
service

ANSIBLE VERSION

ansible 2.3.2.0
  config file = /Users/rsteinfeldt/Documents/discovery-ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.13 (default, Aug  8 2017, 13:46:50) [GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]

CONFIGURATION

None of significance

OS / ENVIRONMENT

N/A

SUMMARY

Both
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/service.py#L536 and
https://github.com/ansible/ansible/blob/stable-2.3/lib/ansible/modules/system/systemd.py#L383
have the same basic logic check failure. Their purposes in each module are essentially the same for the sake of this bug, and both locations need to be fixed:

Neither module properly parses the return code '0' coupled with the stdout value 'indirect'. They return the false positive that a systemd service/Unit file is enabled when it is not, therefore always producing a Changed status and attempting to disable a service when disabling it does nothing.

From the systemctl man page, 0 and indirect indicates that the "Unit file itself is not enabled, but it has a non-empty Also= setting in the "[Install]" section, listing other unit files that might be enabled."

With any systemd service that has an Also= section, ansible will indicate that it has disabled a service that may already be disabled.

STEPS TO REPRODUCE

An RHEL 7 type series linux will show this error well:

1. Install rpcbind package.
2. Run [systemd|service] name="rpcbind.service" state="stopped" enabled="no"
3. Running (2) repeatedly will yield an ansible 'changed' state despite the fact that the service is already stopped and disabled.

EXPECTED RESULTS (My best guess)

"systemctl is-enabled" should interpret stdout strings when the return code is 0 as follows:
enabled* : Service is enabled.
static: Service is disabled, and if a user is attempting to enable the service, return an error.
indirect: Service is disabled.

I suggest that if a user desires to enable/disable/stop/start/query a parallel Unit file that will make a queried unit file return 'indirect', that they should do so explicitly.

ACTUAL RESULTS

A unit service which has a return code of 0 from 'systemctl is-enabled' is assumed to be enabled when it may not be, because stdout return values aren't checked at all.

[ansibot]

cc @dharmabumstead
click here for bot help

[Akasurde]

@skylerbunny Could you please check if PR #77754 resolves the issue? Thanks.

[ansibot]

@skylerbunny This Issue is waiting for your response. Please respond or the Issue will be closed.

click here for bot help

[vbotka]

... Could you please check if PR #77754 resolves the issue?

In Ansible 2.16.6, I'll give you a case where this PR doesn't solve the problem. The below task systemd_service is not idempotent on the remote host Ubuntu 23.10

- systemd_service:
    name: udev.service
    state: started
    enabled: true

The problem triggers the parameter enabled: true. The task is idempotent when I remove it. The service udev.service is alias of systemd-udevd.service

shell> systemctl is-enabled udev.service
alias

shell> systemctl is-enabled systemd-udevd.service
static

The below task with the service systemd-udevd.service is idempotent

- systemd_service:
    name: systemd-udevd.service
    state: started
    enabled: true

IMO, this is the consequence of the conditional from #77754

if out.rstrip() in ("enabled-runtime", "indirect", "alias"):
  enabled = False
else:
  enabled = True

I have no clue how to solve this. The Table 1. is-enabled output in man systemctl shows the complexity of the problem, I think.

[ansibot]

@skylerbunny You have not responded to information requests in this Issue so we will assume it no longer affects you. If you are still interested in this, please create a new Issue with the requested information.

click here for bot help