Systemd test enabled workaround?

Get Help
1

I just came across something I find strange:

- name: Enable the enabled-runtime service using shell command
  shell: systemctl enable --runtime baz

The next task:

- name: Enable enabled-runtime service
  systemd:
    name: baz.service
    enabled: true
  register: baz_test_1

is this the same workaround as in

2

I copied some and tried to run them, seems one failed:

TASK [sysmd : assert] *********************************************************************************************
task path: /home/carl/src/bug_reports/absd/ansible/roles/sysmd/tasks/test_enabled_runtime.yml:42
fatal: [pi3]: FAILED! => {
    "assertion": "baz_test_1 is changed",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}

PLAY RECAP ********************************************************************************************************
pi3                        : ok=24   changed=6    unreachable=0    failed=1    skipped=0    rescued=0    ignored=2

I fixed it:

 - name: Enable the enabled-runtime service using shell command
-  shell: systemctl enable --runtime baz
+  shell: systemctl disable --runtime baz

I’m still not sure what is going on.

3

Doesn’t the service also need to be started?

- name: Enable and start enabled-runtime service
  ansible.builtin.systemd_service:
    name: baz.service
    enabled: true
    state: started
4

@CarlFK

I haven’t read all the messages on Element and I’m not quite sure what you’re trying to do, but from what I’ve seen in the systemd_service module’s code, the --runtime functions are not supported by the module.

You can set user mode and enable the service, but it will not use the --runtime function.

user mode is implemented by appending the appropriate flag to the systemctl command. In the code, you’ll see this right after retrieving systemctl’s binary

So if you set scope: user, the command becomes systemctl --user …, which runs the service in the current user’s context.

The service enabling operation takes place as follows:

It checks the value of the enabled parameter. If it’s true, it sets the action to enable, otherwise to disable.

It compares the current enabled state with the desired state. If they differ, it marks the result as changed and executes the corresponding enable or disable command:

For the runtime enablement, check the section that verifies if a service is enabled. After executing:

the code inspects the output:

if the output is enabled-runtime, the module does not consider the service as permanently enabled and will attempt to change it if enabled: true is requested. This means the module doesn’t support runtime enablement as a permanent configuration.

1 Like