# Should the systemd\_service module include the reset\_failed option?

**URL:** <https://forum.ansible.com/t/should-the-systemd-service-module-include-the-reset-failed-option/40440>\
**Category:** Project Discussions\
**Tags:** dev, module, ansible-core\
**Created:** [February 21, 2025, 7:35pm UTC](https://forum.ansible.com/t/should-the-systemd-service-module-include-the-reset-failed-option/40440 "2025-02-21T19:35:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![NomakCooper](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nomakcooper/32/7309_2.png) [@NomakCooper](https://forum.ansible.com/u/NomakCooper)\
**Post date:** [February 21, 2025, 7:35pm UTC](https://forum.ansible.com/t/should-the-systemd-service-module-include-the-reset-failed-option/40440/1 "2025-02-21T19:35:27Z")

</div>

**Hello everyone,**

Some friends have pointed out to me that using Ansible to manage **`systemd services`** can sometimes lead to unexpected results.

More specifically, services with **`StartLimitBurst`** may fail to start because the unit has exceeded the failed limit.

### What does this mean?

The module does its job well, but unfortunately, `systemctl` commands fail when a service exceeds the limits set by **`StartLimitBurst`** and **`StartLimitIntervalSec`**.

As a result, the failure of these commands is reflected in the module’s failure.

For testing, I used a modified version of the **`ansible_test`** service.

```bash
[Unit]
Description=Ansible Test Service
StartLimitBurst=1
StartLimitIntervalSec=60

[Service]
ExecStart=/usr/sbin/ansible_test_service "Test\nthat newlines in scripts\nwork"
ExecReload=/bin/true
Restart=on-failure
Type=forking
PIDFile=/var/run/ansible_test_service.pid

[Install]
WantedBy=multi-user.target

```

```bash
# systemctl status ansible_test.service
× ansible_test.service - Ansible Test Service
     Loaded: loaded (/etc/systemd/system/ansible_test.service; enabled; preset: disab
     Active: failed (Result: signal) since Fri 2025-02-21 18:53:10 CET; 17min ago
   Duration: 4.504s
    Process: 1887 ExecStart=/usr/sbin/ansible_test_service Test
that newlines in scripts
work (code=exited, status=0/SUCCESS)
   Main PID: 1889 (code=killed, signal=KILL)
        CPU: 892ms

Feb 21 18:53:10 ansiblecn systemd[1]: ansible_test.service: Scheduled restart job, re
Feb 21 18:53:10 ansiblecn systemd[1]: Stopped Ansible Test Service.
Feb 21 18:53:10 ansiblecn systemd[1]: ansible_test.service: Start request repeated to
Feb 21 18:53:10 ansiblecn systemd[1]: ansible_test.service: Failed with result 'signa
Feb 21 18:53:10 ansiblecn systemd[1]: Failed to start Ansible Test Service.
Feb 21 18:53:10 ansiblecn systemd[1]: ansible_test.service: Start request repeated to
Feb 21 18:53:10 ansiblecn systemd[1]: ansible_test.service: Failed with result 'signa
Feb 21 18:53:10 ansiblecn systemd[1]: Failed to start Ansible Test Service.

```

```bash
TASK [try start after fail] *************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to start service ansible_test: 
Job for ansible_test.satus ansible_test.service\" and \"journalctl -xeu ansible_test.service\" 
for details.\n"}

```

### Would it be useful to handle **`reset-failed`** directly within the **`systemd_service`** module?

For testing, I created a local copy of the module and introduced a new **`boolean`** option, **`reset_failed`** , along with a new code block that performs a `reset-failed` on the service before executing **`state`** operations.

```bash
TASK [try start after fail] **************************************************************
changed: [localhost] => {"changed": true, "name": "ansible_test", "state": "started",...}}

```

The rest of the module remains unchanged.

### Would this change be useful? Would it be worth opening an issue and a related PR?

---

<div class="post-metadata">

**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\
**Post date:** [February 22, 2025, 9:08am UTC](https://forum.ansible.com/t/should-the-systemd-service-module-include-the-reset-failed-option/40440/2 "2025-02-22T09:08:09Z")

</div>

I’d find it useful, I have [a handler for this](https://git.coop/webarch/quota/-/blob/5ca110b46de9d1f9a1288af8dc71cfc5ed9df2d9/handlers/main.yml#L35) in one role:

```yaml
    - name: Reset failed # noqa: no-changed-when
      ansible.builtin.command: systemctl reset-failed
      listen: Reset failed

```

---

<div class="post-metadata">

**Author:** ![awkohr](https://avatars.discourse-cdn.com/v4/letter/a/c5a1d2/32.png) [@awkohr](https://forum.ansible.com/u/awkohr)\
**Post date:** [October 8, 2025, 6:44pm UTC](https://forum.ansible.com/t/should-the-systemd-service-module-include-the-reset-failed-option/40440/3 "2025-10-08T18:44:49Z")

</div>

I think it would be very useful as I am dealing with a situation where a service (mcelog) just doesn’t work in vmware, and after stopping the service I wanted to also reset the failure and was not seeing a way to do that in this module, I switched to doing it via ansible.builtin.command with cmd of “systemctl reset-failed mcelog.service” to do it. That works but has the downfall of ansible-lint throwing a warning violation of “command-instead-of-module: systemctl used in place of systemd module.”

I would think if the module isn’t modified, then maybe an issue should be submitted that ansbile-lint should be modified not to only give that warning when the systemd\_service commands support what you are doing and not complain about other systemctl service commands that it does not support.