Module systemd_service Ansible : démarrer, activer, recharger

Sur RHEL 7+, Ubuntu 16.04+ et toute distribution moderne, ansible.builtin.systemd_service est le module recommandé pour gérer les services. Il remplace l'ancien service: (encore présent mais legacy) avec des options spécifiques à systemd : daemon_reload:, masked:, et la distinction claire entre state: (état actuel) et enabled: (au boot).

Cas d'usage typiques RHCE 2026 : démarrer sshd, chronyd, firewalld ; déposer un unit file custom pour un service applicatif ; masquer un service dangereux (rpcbind, cups).

# 1. Démarrer + activer au boot (les 2 sont indépendants)
- ansible.builtin.systemd_service:
    name: chronyd
    state: started
    enabled: true     # démarre aussi au reboot
  become: true

# 2. Après dépôt d'un unit file custom : daemon_reload obligatoire
- ansible.builtin.copy:
    src: files/myapp.service
    dest: /etc/systemd/system/myapp.service
    owner: root
    group: root
    mode: "0644"
  become: true
- ansible.builtin.systemd_service:
    name: myapp
    state: started
    enabled: true
    daemon_reload: true   # systemd relit les units après modification
  become: true

# 3. Recharger une config (préférer "reloaded" à "restarted" — pas de coupure)
- ansible.builtin.systemd_service:
    name: nginx
    state: reloaded
  become: true

# 4. Masquer un service dangereux (durcissement)
- ansible.builtin.systemd_service:
    name: rpcbind
    state: stopped
    enabled: false
    masked: true       # interdit toute tentative de start (même manuelle)
  become: true

Sécurité non négociable :

state: started (immédiat) et enabled: true (au boot) sont indépendants, il faut les deux pour qu'un service survive à un reboot.
reloaded plutôt que restarted quand le service le supporte (nginx, httpd, sshd), pas de coupure de service en prod.
daemon_reload: true mandatory après tout dépôt/modif de .service dans /etc/systemd/system/, sinon systemd lit l'ancien fichier.
masked: true est le verrou ultime contre un service indésirable, il empêche même un systemctl start manuel ; à appliquer au durcissement (rpcbind, cups, avahi-daemon).
Permissions du unit file : 0644 root:root, un unit file world-writable est une élévation de privilèges instantanée.

Ce que vous allez apprendre

La distinction state: vs enabled:, pourquoi les deux options sont nécessaires.
L'option daemon_reload: true après modification d'un unit file .service.
Le mécanisme masked: true, empêcher tout démarrage du service.
La différence reloaded vs restarted, recharger sans coupure.

Prérequis

Connaître les bases de systemd (systemctl start, enable, status).
Avoir lu Module package, l'installation précède toujours le start.

state vs enabled, deux options indépendantes

- name: Demarrer sshd MAINTENANT
  ansible.builtin.systemd_service:
    name: sshd
    state: started

state: gère l'état immédiat : started (démarrer si arrêté), stopped, restarted (redémarrer toujours), reloaded (rechargement à chaud).

- name: Activer sshd au BOOT
  ansible.builtin.systemd_service:
    name: sshd
    enabled: true

enabled: gère le démarrage au boot : true (équivalent systemctl enable), false (équivalent systemctl disable).

Les deux sont indépendants : un service peut être démarré sans être enabled (start manuel après un reboot), ou enabled mais arrêté (planifié pour le prochain reboot). En production, les deux ensemble est l'usage standard :

- name: Demarrer ET activer sshd
  ansible.builtin.systemd_service:
    name: sshd
    state: started
    enabled: true

restarted vs reloaded

`state:`	Effet	Coupure ?
`restarted`	Stop + Start (redémarre le processus)	Oui, brève (ms à quelques secondes selon le service)
`reloaded`	Envoie `SIGHUP` (rechargement de config)	Non, pas d'arrêt, juste reload

Préférer reloaded quand le service le supporte (nginx, httpd, sshd, firewalld), pas de coupure pour les clients connectés. restarted reste nécessaire pour un changement d'unit file ou un changement majeur que SIGHUP ne couvre pas.

daemon_reload, recharger systemd lui-même

Quand on dépose un nouveau unit file dans /etc/systemd/system/, systemd ne le voit pas tant qu'on n'a pas fait systemctl daemon-reload. Sans ça, start échouerait avec "unit not found".

- name: Deposer unit file myapp
  ansible.builtin.copy:
    src: files/myapp.service
    dest: /etc/systemd/system/myapp.service
    mode: "0644"

- name: Recharger systemd et demarrer myapp
  ansible.builtin.systemd_service:
    name: myapp
    state: started
    enabled: true
    daemon_reload: true

daemon_reload: true déclenche systemctl daemon-reload avant d'agir sur myapp, l'unit file est pris en compte, puis le service démarre.

Pas besoin de daemon_reload si vous modifiez juste l'état d'un service existant (state: started sur sshd). Réservé aux nouveaux unit files ou aux modifs d'un unit file existant.

masked, interdire le start

- name: Masquer rpcbind (interdit toute tentative de start)
  ansible.builtin.systemd_service:
    name: rpcbind
    state: stopped
    enabled: false
    masked: true

masked: true lie l'unit file à /dev/null, toute commande systemctl start rpcbind échoue silencieusement, même par un humain. Pattern de durcissement pour des services qu'on interdit absolument.

Différence avec enabled: false : disabled empêche le démarrage au boot, mais systemctl start <service> manuel marche encore. masked interdit toute forme de démarrage.

Démarrer plusieurs services, boucle

- name: Demarrer la stack monitoring
  ansible.builtin.systemd_service:
    name: "{{ item }}"
    state: started
    enabled: true
  loop:
    - prometheus
    - grafana-server
    - node_exporter

Chaque itération est une opération systemd indépendante. Pour 50 services, c'est lent, mais c'est rare d'avoir 50 services à démarrer en parallèle.

Notification depuis un handler

Pattern classique : modifier sshd_config → recharger sshd via un handler.

- name: Modifier sshd_config
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?PermitRootLogin'
    line: 'PermitRootLogin no'
  notify: Reload sshd

handlers:
  - name: Reload sshd
    ansible.builtin.systemd_service:
      name: sshd
      state: reloaded

Le handler ne tourne qu'à la fin du play (et seulement si la tâche a notifié). Voir Handlers pour le détail.

Pièges courants

Symptôme	Cause	Fix
"Unit not found" après `copy:` d'un unit file	Pas de `daemon_reload`	Ajouter `daemon_reload: true`
Service démarre au play mais pas au reboot	`enabled: false` (ou pas spécifié)	Ajouter `enabled: true`
`state: reloaded` échoue	Service ne supporte pas SIGHUP	Utiliser `state: restarted`
`systemctl start <service>` marche en CLI mais pas après mask	Service est masked	`masked: false` puis `state: started`
`enabled: true` mais service ne démarre pas au boot	Unit file n'a pas de `[Install]` section	Ajouter `[Install]\nWantedBy=multi-user.target` à l'unit file

À retenir

state: = état immédiat (start/stop/restart/reload). enabled: = démarrage au boot. Indépendants.
daemon_reload: true est obligatoire après un nouveau unit file ou une modif d'un unit existant.
reloaded > restarted quand le service le supporte, pas de coupure.
masked: true est l'arme nucléaire, interdit tout start, même manuel.
Section [Install] dans l'unit file est obligatoire pour que enabled: true fonctionne.

Pratiquer dans le lab

Cette page a un lab d'accompagnement : labs/modules-services/systemd/ dans stephrobert/ansible-training.

Challenge, sur web1.lab :

Installer chrony (NTP).
Démarrer + activer chronyd.
Déposer un unit file custom lab-marker.service (oneshot RemainAfterExit).
daemon_reload + start + enable lab-marker.

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-services/systemd/challenge/tests/

5 tests vérifient chrony installé, chronyd actif et activé, l'unit file présent, lab-marker activé et /var/run/lab-marker.flag touché.

Prochaines étapes

Module package L'installation précède toujours le start, base nécessaire

Module dnf, options RHEL enablerepo, security, exclude, pour des installations fines

Module cron Planifier des tâches récurrentes (backup, cleanup) en complément des services

Handlers et notification Le pattern reload-on-config-change pour les services managed