Ansible Service State and Enablement
Two independent questions - is it running now, and will it run after a reboot - and two independent parameters. Then the one that catches everyone: systemd caches unit files, so writing a new one changes nothing until `daemon_reload`. This installs a real unit, proves the caching, and covers the states that can never be idempotent.
Automating Administration Guide 30 of 45 Intermediate
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 16 min
- Reviewed23 August 2026
Written against the versions above. This lab is Ubuntu 26.04 and EX294 is a RHEL exam. systemd is the same on both, so this guide is one of the few in this track that is unchanged for EX294. `ansible.builtin.service` is the generic module; `systemd_service` is the systemd-specific one and the only one with `daemon_reload`.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| ANS-CTL01 | 192.168.0.36 | Ubuntu 26.04 LTS | Ansible Control Node | 2 Core | 3 GB | 50 GB |
| ANS-A01 | 192.168.0.37 | Ubuntu 26.04 LTS | Managed Node (group: web) | 2 Core | 3 GB | 50 GB |
Before you start
- A control node configured as shown in the first step.
- The session writes
/etc/systemd/system/demoapp.service, runs it, and removes it.
-
The configuration this guide assumes
-
started and enabled are two different questions
-
A unit file of your own
-
What happens without daemon_reload
-
restarted is never idempotent
-
Asking what is running