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
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 |
This guide includes
Use this when a service works today and is gone after a reboot. This matters because running now and starting at boot are two independent questions - and restarted is never idempotent.
- separating
statefromenabled, which answer two different questions - writing a unit file of your own
- finding what happens when you skip
daemon_reload - seeing
restartedreport changed every single time - asking what is running, using service facts
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