Linux systemd avancé : services, journalctl et timers

À la fin de ce bonus systemd timer, vous saurez structurer un unit file (Type=, Restart=, User=, WorkingDirectory=), inspecter avec systemctl cat / daemon-reload, filtrer journalctl (-u, -f, -p err, --since/--until, -o short-iso), et planifier une tâche cron-like avec un couple .timer + .service (OnCalendar, Persistent=true, list-timers).

Niveau : Débutant+ · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-10

Slug proposé : linux-systemd-avance · Série : Shell / linux-shell-automation (hors menu Basics — draft conservé) · Remplace / fusionne : N/A — création

Prérequis

• Avoir suivi Processus & systemd (systemctl, service lab minimal, aperçu timers)
• VM ou WSL jetable avec systemd actif (Ubuntu/Debian recommandés ; Rocky/Alma 9 OK)
• Terminal bash ; lab dans /tmp et ~/.config/systemd/user/ (variante system avec sudo possible)
• Pas de secrets, tokens ni mots de passe dans les unit files ni les scripts

Coût estimé : 0 €. Aucun paquet obligatoire au-delà de systemd (présent par défaut).

Ce que nous allons construire

Unit file (Type=simple|oneshot, Restart, User, WorkingDirectory)
  → systemctl cat · daemon-reload
  → journalctl avancé (-u -f -p --since --until -o short-iso)
  → Timer : .timer + .service · OnCalendar · Persistent=true
  → Lab backup/log cron-like dans /tmp
  → list-timers · nettoyage · erreurs · quiz · FAQ

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « systemd avancé : unit file, journalctl, timer OnCalendar et service oneshot — lab Linux Basics ».)

Bonus de Linux Basics, prolongement du chapitre 5 processus & systemd. Un systemd timer remplace souvent un cron pour les tâches machine-aware (logs unifiés, Persistent=true après downtime). Analogie ops : un Job / CronJob Kubernetes planifie aussi une charge utile — voir Docker débutant et la série Kubernetes.

Étape 1 — Anatomie d’un unit file service

Un fichier .service a trois sections courantes : [Unit], [Service], [Install].

Directive	Rôle lab
Type=simple	Processus principal = ExecStart (daemon long)
Type=oneshot	Tâche qui finit ; idéal pour scripts backup / log
RemainAfterExit=yes	Avec oneshot : l’unit reste « active » après succès
Restart=	no / on-failure / always — prudence en lab
User= / Group=	Identité d’exécution (system units)
WorkingDirectory=	cwd avant ExecStart

# Lire un unit réel sans l’éditer (fusion drop-ins incluse)
systemctl cat cron.service 2>/dev/null || systemctl cat crond.service 2>/dev/null || systemctl cat ssh.service
# Voir le chemin et les overrides
systemctl show -p FragmentPath -p DropInPaths cron.service 2>/dev/null 
  || systemctl show -p FragmentPath crond.service 2>/dev/null || true

Ubuntu/Debian : souvent cron.service. Rocky/Alma : crond.service. Même systemctl cat / daemon-reload partout.

Après toute modification d’un unit sous /etc/systemd/system/ ou ~/.config/systemd/user/ : daemon-reload (sinon systemd ignore le nouveau contenu).

Étape 2 — journalctl : filtres utiles au quotidien

Le tuto 5 a vu -u, -f, --since. Affinez le diagnostic.

UNIT=$(systemctl list-units --type=service --all 'ssh*' 'sshd*' 2>/dev/null | awk '/loaded/ {print $1; exit}')
UNIT="${UNIT:-cron.service}"
# Dernières erreurs / warnings de l’unit
journalctl -u "$UNIT" -p err -n 30 --no-pager
# Fenêtre temporelle + format ISO court
journalctl -u "$UNIT" --since "2 hours ago" --until "now" -o short-iso --no-pager | tail -n 20
# Suivi live (Ctrl+C) — commenté pour scripts non interactifs
# journalctl -u "$UNIT" -f -o short-iso

Option	Effet
-u nom	Filtrer par unit
-f	Follow (comme tail -f)
-p err	Priorité ≥ erreur (warning, info, …)
--since / --until	Fenêtre ("2026-09-10", "10 min ago")
-o short-iso	Horodatage ISO lisible pour coller dans un ticket

Sur Rocky comme sur Ubuntu : même journalctl. Sans droits root, préférez journalctl --user -u … pour vos units user.

Étape 3 — Timers : .timer + .service et OnCalendar

Un systemd timer déclenche un service du même radical (lab-backup.timer → lab-backup.service). Ce n’est pas un remplacement magique de cron partout, mais c’est l’outil natif quand le reste de la machine vit déjà dans systemd.

Élément	Rôle
.service (Type=oneshot)	Charge utile (script)
.timer	Calendrier / intervalle
OnCalendar=	Expression calendrier (hourly, daily, *-*-* 02:30:00)
Persistent=true	Rattrapage si la machine était éteinte
list-timers	Prochaines déclenchements

Vérifier la syntaxe calendrier : systemd-analyze calendar '*-*-* 02:30:00'.

Étape 4 — Lab : script backup/log + timer user

Objectif : toutes les minutes (lab), un script écrit une ligne datée dans /tmp — équivalent cron-like sans toucher à crontab.

# 1) Script jetable
mkdir -p /tmp/lab-systemd-avance "$HOME/.config/systemd/user"
cat > /tmp/lab-systemd-avance/backup-lab.sh << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
LOG=/tmp/lab-systemd-avance/backup.log
STAMP=$(date -Is)
echo "[lab-backup] run at ${STAMP} pid=$$ host=$(hostname -s)" >> "$LOG"
# « Backup » simulé : copie d’un fichier marqueur
echo "ok ${STAMP}" > /tmp/lab-systemd-avance/last-ok.txt
cp -a /tmp/lab-systemd-avance/last-ok.txt "/tmp/lab-systemd-avance/last-ok.${STAMP}.txt" 2>/dev/null || true
# Garder peu de copies en lab
ls -1t /tmp/lab-systemd-avance/last-ok.*.txt 2>/dev/null | tail -n +6 | xargs -r rm -f
SCRIPT
chmod +x /tmp/lab-systemd-avance/backup-lab.sh

# 2) Service oneshot (user)
cat > "$HOME/.config/systemd/user/lab-backup.service" << 'UNIT'
[Unit]
Description=Lab backup/log oneshot (Linux Basics systemd avancé)
Documentation=file:///tmp/lab-systemd-avance/

[Service]
Type=oneshot
WorkingDirectory=/tmp/lab-systemd-avance
ExecStart=/tmp/lab-systemd-avance/backup-lab.sh
# Restart= inutile pour oneshot réussi ; on-failure possible si vous testez des échecs
UNIT

# 3) Timer OnCalendar (toutes les minutes en lab)
cat > "$HOME/.config/systemd/user/lab-backup.timer" << 'TIMER'
[Unit]
Description=Timer lab backup/log (OnCalendar minutely)

[Timer]
OnCalendar=minutely
Persistent=true
Unit=lab-backup.service

[Install]
WantedBy=timers.target
TIMER

# 4) Activer le timer (pas besoin de start manuel du service)
systemctl --user daemon-reload
systemctl --user enable --now lab-backup.timer
systemctl --user list-timers --all | grep -E 'lab-backup|NEXT' || systemctl --user list-timers --all | head
# Déclenchement immédiat de test
systemctl --user start lab-backup.service
sleep 1
tail -n 5 /tmp/lab-systemd-avance/backup.log
systemctl --user status lab-backup.timer --no-pager

Si Failed to connect to bus : loginctl enable-linger "$USER" (lab) ou variante system :

# Variante system (VM lab + sudo) — optionnelle
# sudo cp "$HOME/.config/systemd/user/lab-backup."{service,timer} /etc/systemd/system/
# # Ajoutez User=votrelogin et WorkingDirectory= dans le .service system si besoin
# sudo systemctl daemon-reload
# sudo systemctl enable --now lab-backup.timer
# sudo systemctl list-timers | grep lab-backup
# sudo journalctl -u lab-backup.service -n 20 --no-pager -o short-iso

Attendez ~1–2 min puis tail le log : une nouvelle ligne confirme le systemd timer. En prod vous choisiriez OnCalendar=*-*-* 02:30:00 (ex. backup nocturne), pas minutely.

Étape 5 — Vérification, journal du lab et nettoyage

# Vérifs
systemctl --user is-active lab-backup.timer
systemctl --user list-timers lab-backup.timer --no-pager
journalctl --user -u lab-backup.service -n 15 -o short-iso --no-pager 2>/dev/null || true
test -s /tmp/lab-systemd-avance/backup.log && echo "log OK" || echo "log manquant"
cat /tmp/lab-systemd-avance/last-ok.txt

# Nettoyage lab (disable timer + rm units + /tmp)
systemctl --user disable --now lab-backup.timer 2>/dev/null || true
systemctl --user stop lab-backup.service 2>/dev/null || true
rm -f "$HOME/.config/systemd/user/lab-backup.service" 
      "$HOME/.config/systemd/user/lab-backup.timer"
systemctl --user daemon-reload
rm -rf /tmp/lab-systemd-avance
# Variante system si utilisée :
# sudo systemctl disable --now lab-backup.timer
# sudo rm -f /etc/systemd/system/lab-backup.{service,timer}
# sudo systemctl daemon-reload
systemctl --user list-timers --all 2>/dev/null | grep lab-backup || echo "lab nettoyé — OK"

Validé si : systemctl cat OK, daemon-reload après édition, journalctl filtré, timer active, au moins une ligne dans le log lab, puis disable + rm.

Erreurs fréquentes

Symptôme	Cause	Correction
Unit inchangé après edit	Pas de daemon-reload	systemctl [--user] daemon-reload puis restart / start
Timer actif, service jamais lancé	Mauvais radical / Unit=	Même préfixe lab-backup.* ; list-timers
Failed to connect to bus	Session user systemd absente	linger, reconnexion, ou unit system en lab
journalctl vide	Mauvais -u ou scope	Nom exact (status) ; --user vs system
OnCalendar rejeté	Syntaxe invalide	systemd-analyze calendar '…'
Timer ne rattrape pas le downtime	Persistent absent	Persistent=true dans [Timer]
Type=simple + script court	Service « dead » tout de suite	Préférez Type=oneshot (+ RemainAfterExit si besoin)

Quiz (3 questions)

1. À quoi sert daemon-reload après avoir modifié un unit file ?
– A. À redémarrer toute la machine
– B. À faire relire les units (chemins / contenu) par systemd avant start/enable
– C. Uniquement à vider journalctl

2. Quelle combinaison convient à une tâche backup qui s’arrête toute seule ?
– A. .timer + .service en Type=oneshot avec OnCalendar
– B. Uniquement kill -9 en boucle
– C. Type=simple sans ExecStart

3. Que permet Persistent=true sur un systemd timer ?
– A. De chiffrer le journal
– B. De déclencher les runs manqués si la machine était éteinte au créneau OnCalendar
– C. De remplacer User=

Réponses : 1‑B · 2‑A · 3‑B

FAQ

Comment créer un service systemd custom ?
Écrivez un .service (Type=simple ou oneshot, ExecStart=, optionnellement User=, WorkingDirectory=, Restart=), placez-le en user (~/.config/systemd/user/) ou system (/etc/systemd/system/), puis daemon-reload et enable --now. Inspectez avec systemctl cat.

Comment lire journalctl pour un unit précis ?
journalctl -u nom.service ; affinez avec -f, -p err, --since / --until, -o short-iso. Pour un unit user : journalctl --user -u nom.service.

systemd timer ou cron ?
Les deux restent valides. Un systemd timer s’intègre aux units, au journal et à Persistent=true ; cron reste simple pour des crontabs utilisateur legacy. En 2026, pour une machine déjà pilotée par systemd, le couple .timer + .service est souvent le plus clair.

Pour aller plus loin

• man systemd.service, man systemd.timer, man systemd.time, man journalctl, man systemctl
• Chapitre socle : Processus & systemd
• Bonus sécurité hôte : ufw + fail2ban
• Orchestration : Docker débutant · Jobs/CronJobs (série Kubernetes)

Maillage série Linux Basics (P5)

← Précédent	Contrôler processus et services Linux
→ Aussi bonus	Sécuriser un VPS avec ufw et fail2ban
Hub	Linux Basics
Aussi	Docker débutant · analogie Jobs/CronJobs (série K8s)

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : systemd avancé : journalctl, timers et services (2026)
• Meta description (≤ 155) : Créez un service systemd, lisez journalctl, planifiez avec des timers. Bonus série Linux Basics DevOps.
• Focus keyphrase : systemd timer
• KW secondaires : journalctl, unit file, OnCalendar, systemd service linux
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-systemd-avance-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Débutant+
• Slug : linux-systemd-avance
• URL : /tutoriels/linux-systemd-avance/

← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.