Planifier des tâches avec les timers systemd sous Linux

Les timers systemd sont l'alternative moderne à cron. Ils planifient l'exécution de services systemd selon un calendrier (OnCalendar) ou après un délai (OnBootSec, OnUnitActiveSec). Leur avantage principal : la journalisation via journalctl, la gestion des dépendances et la possibilité de rattraper les exécutions manquées avec Persistent=true.

Ce que vous allez apprendre

• Lister les timers actifs et comprendre leur état
• Distinguer un timer calendaire (OnCalendar) d'un timer monotone (OnBootSec)
• Analyser un timer existant comme apt-daily.timer
• Créer un timer personnalisé avec son service associé
• Activer la persistance pour rattraper les exécutions manquées
• Valider la syntaxe d'un calendrier avec systemd-analyze calendar

Dans quel contexte ?

Les timers systemd remplacent progressivement cron sur les distributions modernes :

• Exécuter une sauvegarde quotidienne avec journalisation automatique
• Planifier un nettoyage de fichiers temporaires avec contrôle fin de l'intervalle
• Déclencher une tâche 15 minutes après le démarrage du système
• S'assurer qu'une tâche manquée (machine éteinte) sera rattrapée au prochain démarrage
• Bénéficier de journalctl pour diagnostiquer les erreurs d'un job planifié

LFCS / RHCSA

Le référentiel RHCSA (EX200, sur RHEL 10) cite les timers en toutes lettres : « Schedule tasks using at, cron and systemd timer units ». Vous devez savoir créer un timer, l'activer et vérifier son fonctionnement. Le LFCS ne nomme aucun outil et demande de savoir « Manage or schedule jobs for executing commands », dans le domaine Operations Deployment.

Les timers actifs

Pour voir tous les timers du système :

systemctl list-timers --all

NEXT                              LEFT LAST                              PASSED UNIT                    ACTIVATES
Sat 2026-06-28 14:19:18 CEST  1h 28min Sat 2026-06-28 06:32:32 CEST      6h ago apt-daily.timer         apt-daily.service
Sun 2026-06-29 00:00:00 CEST       11h Sat 2026-06-28 00:00:14 CEST     12h ago dpkg-db-backup.timer    dpkg-db-backup.service
Sun 2026-06-29 00:23:41 CEST       11h Sat 2026-06-28 00:41:07 CEST     12h ago logrotate.timer         logrotate.service
Sun 2026-06-29 06:19:57 CEST       17h Sat 2026-06-28 06:44:19 CEST      6h ago apt-daily-upgrade.timer apt-daily-upgrade.service

Cette sortie d'exemple vient d'une Debian : les lignes sont triées par prochaine échéance, et les heures irrégulières (00:23:41, 06:19:57) viennent du délai aléatoire que ces timers ajoutent, expliqué plus bas avec RandomizedDelaySec. Chaque ligne montre :

Colonne	Signification
NEXT	Prochaine exécution prévue
LEFT	Temps restant avant la prochaine exécution
LAST	Dernière exécution
PASSED	Temps écoulé depuis la dernière exécution
UNIT	Nom du timer
ACTIVATES	Service déclenché

Glissez pour voir

Deux types de timers

Un timer se déclenche soit à une date et heure données, soit après un délai compté depuis un événement du système. Les deux formes peuvent coexister dans la même unité, systemd retenant alors l'échéance la plus proche.

Timer calendaire (OnCalendar)

Déclenché à un moment précis, comme cron. Utilise le format OnCalendar :

[Timer]
OnCalendar=*-*-* 03:00:00

Équivalent cron : 0 3 * * * (chaque jour à 3 h).

Timer monotone

Déclenché après un délai relatif à un événement (démarrage, dernière exécution, activation) :

[Timer]
OnBootSec=15min
OnUnitActiveSec=1h

Ce timer se déclenche 15 minutes après le démarrage, puis toutes les heures.

Directive	Déclenchement relatif à
OnBootSec	Le démarrage du système
OnStartupSec	Le démarrage de systemd (espace utilisateur)
OnActiveSec	L'activation du timer lui-même
OnUnitActiveSec	La dernière activation du service associé
OnUnitInactiveSec	La dernière désactivation du service associé

Glissez pour voir

Analyser un timer existant

Prenons apt-daily.timer, présent sur Debian/Ubuntu :

systemctl cat apt-daily.timer

[Unit]
Description=Daily apt download activities

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Décryptage

Directive	Effet
OnCalendar=*-*-* 6,18:00	Se déclenche à 6 h et 18 h chaque jour
RandomizedDelaySec=12h	Ajoute un délai aléatoire jusqu'à 12 h pour étaler la charge
Persistent=true	Si l'exécution a été manquée (machine éteinte), elle est rattrapée au prochain démarrage

Glissez pour voir

# Voir le service associé
systemctl cat apt-daily.service

Convention de nommage

Un timer mon-job.timer déclenche automatiquement le service mon-job.service (même nom, extension différente). Vous pouvez changer ce comportement avec Unit= dans la section [Timer].

Syntaxe OnCalendar

La syntaxe OnCalendar est plus expressive que cron :

DayOfWeek Year-Month-Day Hour:Minute:Second

Exemples courants

Chaque expression ci-dessous a été passée à systemd-analyze calendar avec systemd 257 : la forme normalisée qu'il renvoie confirme la lecture donnée dans la colonne de droite. Notez que weekly vise le lundi à minuit, là où le @weekly de cron vise le dimanche.

Expression	Signification
*-*-* 03:00:00	Chaque jour à 3 h
Mon..Fri *-*-* 08:00:00	Du lundi au vendredi à 8 h
*-*-01 00:00:00	Le 1er de chaque mois à minuit
weekly	Chaque semaine (lundi 00:00)
daily	Chaque jour (00:00)
hourly	Chaque heure
*-*-* *:00/15:00	Toutes les 15 minutes
Sat *-*-* 22:00:00	Chaque samedi à 22 h

Glissez pour voir

Valider avec systemd-analyze

systemd-analyze calendar vérifie la syntaxe et affiche les prochaines exécutions :

systemd-analyze calendar 'Mon..Fri *-*-* 08:00'

  Original form: Mon..Fri *-*-* 08:00
Normalized form: Mon..Fri *-*-* 08:00:00
    Next elapse: Mon 2026-06-29 08:00:00 CEST
       (in UTC): Mon 2026-06-29 06:00:00 UTC
       From now: 19h left

# Tester un calendrier avec plusieurs occurrences
systemd-analyze calendar --iterations=5 'daily'

Toujours tester la syntaxe

Avant de modifier un timer en production, validez l'expression avec systemd-analyze calendar. Le conseil est bon, mais pas pour la raison qu'on croit : une erreur de syntaxe dans OnCalendar n'est pas toujours silencieuse, et le comportement dépend du reste du fichier.

Si l'expression fautive est le seul planning de l'unité, systemd refuse de charger le timer, et enable --now échoue franchement en rc=1 :

Failed to start atelier.timer: Unit atelier.timer has a bad unit file setting.

systemctl status le confirme avec Loaded: bad-setting. Le silence n'arrive que s'il reste au moins un OnCalendar valide : la ligne fautive est alors simplement ignorée, l'unité se charge et affiche même un Trigger: rassurant, calculé sur la seule expression correcte. Dans ce cas, seul systemd-analyze verify révèle le problème :

systemd-analyze verify /etc/systemd/system/atelier.timer

/etc/systemd/system/atelier.timer:2: Failed to parse calendar specification, ignoring: tous-les-jours 03:00

Créer un timer personnalisé

Créons un timer qui nettoie /tmp chaque jour à 4 h.

1. Créer le service

   sudo systemctl edit --full --force cleanup-tmp.service

   [Unit]
   Description=Nettoyage des fichiers temporaires de plus de 7 jours
   
   [Service]
   Type=oneshot
   ExecStart=/usr/bin/find /tmp -type f -mtime +7 -delete

2. Créer le timer

   sudo systemctl edit --full --force cleanup-tmp.timer

   [Unit]
   Description=Timer quotidien de nettoyage /tmp
   
   [Timer]
   OnCalendar=*-*-* 04:00:00
   Persistent=true
   
   [Install]
   WantedBy=timers.target

3. Activer et démarrer le timer

   systemctl edit recharge lui-même la configuration ; le daemon-reload ne devient indispensable que si vous créez les fichiers à la main dans /etc/systemd/system/.

   sudo systemctl daemon-reload
   sudo systemctl enable --now cleanup-tmp.timer

4. Vérifier le timer

   systemctl status cleanup-tmp.timer

   ● cleanup-tmp.timer - Timer quotidien de nettoyage /tmp
        Loaded: loaded (/etc/systemd/system/cleanup-tmp.timer; enabled)
        Active: active (waiting)
       Trigger: Sun 2026-06-29 04:00:00 CEST; 15h left

5. Tester le service manuellement

   sudo systemctl start cleanup-tmp.service
   systemctl status cleanup-tmp.service

Timer utilisateur (sans sudo)

Les timers utilisateur se placent dans ~/.config/systemd/user/ et n'ont pas besoin de privilèges root. Le spécificateur %h désigne le répertoire personnel de l'utilisateur, ce qui évite d'écrire son chemin en dur :

mkdir -p ~/.config/systemd/user

# Créer le service
cat > ~/.config/systemd/user/mon-backup.service << 'EOF'
[Unit]
Description=Sauvegarde personnelle

[Service]
Type=oneshot
ExecStart=%h/scripts/backup.sh
EOF

# Créer le timer
cat > ~/.config/systemd/user/mon-backup.timer << 'EOF'
[Unit]
Description=Timer de sauvegarde personnelle

[Timer]
OnCalendar=*-*-* 20:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

# Activer
systemctl --user daemon-reload
systemctl --user enable --now mon-backup.timer
systemctl --user list-timers

Options avancées

Ces trois réglages décident du comportement réel du timer sur une machine qui n'est pas allumée en permanence, ou qui doit lancer plusieurs tâches au même instant.

AccuracySec

Par défaut, systemd regroupe les timers dans une fenêtre d'une minute pour économiser les réveils CPU. AccuracySec contrôle cette précision ; 1s demande une exécution précise à la seconde :

[Timer]
OnCalendar=*-*-* 03:00:00
# Exécution précise à la seconde
AccuracySec=1s

Le commentaire est sur sa propre ligne, et ce n'est pas un détail de présentation : une unité systemd n'accepte aucun commentaire en fin de ligne. Écrit AccuracySec=1s # précis, le réglage est rejeté puis ignoré, et systemd-analyze verify le signale par Failed to parse ... ignoring (mesuré avec systemd 255 et 257). La précision à l'heure convient en revanche aux tâches qui ne sont pas pressées : le logrotate.timer d'Ubuntu 24.04 porte AccuracySec=1h.

RandomizedDelaySec

Ajoute un délai aléatoire pour éviter que toutes les machines lancent la même tâche simultanément. Ici, l'exécution est étalée sur quatre heures après minuit :

[Timer]
OnCalendar=daily
# Étalement sur 4 heures
RandomizedDelaySec=4h

C'est le choix fait par Debian 13 et AlmaLinux 10 pour leur logrotate.timer, qui porte RandomizedDelaySec=1h au lieu du AccuracySec=1h d'Ubuntu : les deux évitent un réveil à minuit pile sur tout un parc.

Persistent

Persistent=true rattrape les exécutions manquées. Si la machine était éteinte à l'heure prévue, le timer se déclenche dès son activation au prochain démarrage. Le manuel systemd.timer(5) précise que ce réglage n'a d'effet qu'avec OnCalendar : sur un timer purement monotone (OnBootSec, OnUnitActiveSec), il est accepté sans message mais ne change rien.

[Timer]
OnCalendar=daily
Persistent=true

Toujours activer Persistent

Pour les tâches de maintenance (sauvegardes, nettoyage, rotation) planifiées par OnCalendar, activez systématiquement Persistent=true. C'est le principal avantage des timers sur cron, qui ne rattrape rien sans anacron.

cron vs timers systemd

Critère	cron	Timers systemd
Journalisation	syslog ou fichier	journalctl -u service
Dépendances	Aucune	After=, Requires=
Rattrapage	Non (anacron partiellement)	Persistent=true
Précision	À la minute	À la seconde (avec AccuracySec=1s)
Aléatoire	Non	RandomizedDelaySec
Timer monotone	Non	OnBootSec, OnUnitActiveSec
Sécurité (sandboxing)	Non	Toutes les options systemd
Simplicité	Une ligne suffit	Deux fichiers (.timer + .service)
Universalité	Disponible partout	Systèmes avec systemd

Glissez pour voir

Quand garder cron ?

cron reste pertinent pour les tâches simples (une ligne), sur les systèmes sans systemd, ou quand la syntaxe à 5 champs est plus lisible pour votre équipe. Les deux coexistent sans conflit.

Dépannage

Un timer met en jeu deux unités, et la première question est toujours de savoir laquelle est en cause : le timer n'a-t-il pas déclenché, ou le service a-t-il échoué une fois lancé ? systemctl list-timers répond pour le premier (colonne LAST), journalctl -u pour le second.

Symptôme	Cause probable	Solution
Timer n'apparaît pas dans list-timers	Timer non activé	systemctl enable --now mon.timer
enable --now échoue, Loaded: bad-setting	Seule ligne OnCalendar invalide	Corriger l'expression, la tester avec systemd-analyze calendar
Une échéance ne se déclenche jamais, aucune erreur affichée	Une ligne OnCalendar fautive ignorée à côté d'une valide	systemd-analyze verify sur le fichier .timer
Réglage sans effet (AccuracySec, RandomizedDelaySec...)	Commentaire en fin de ligne, réglage ignoré	Placer le commentaire sur sa propre ligne, contrôler avec systemd-analyze verify
Service échoue silencieusement	Erreur dans ExecStart	journalctl -u mon-service.service
Timer déclenché jusqu'à une minute en retard	AccuracySec vaut 1 min par défaut	AccuracySec=1s si la seconde compte
Exécution manquée non rattrapée	Persistent absent	Ajouter Persistent=true
Timer utilisateur inactif après reboot	Session non persistante	loginctl enable-linger $USER

Glissez pour voir

# Diagnostiquer un timer
systemctl status mon-job.timer
journalctl -u mon-job.service --since today

# Vérifier la prochaine exécution d'une expression
systemd-analyze calendar '*-*-* 04:00:00'

# Détecter les réglages ignorés dans le fichier
systemd-analyze verify /etc/systemd/system/mon-job.timer

# Forcer un déclenchement immédiat
sudo systemctl start mon-job.service

Mettre en pratique

Créez un timer systemd pour une tâche récurrente sur une VM, avec son unité de service, puis vérifiez son déclenchement et sa persistance.

Lab guidé Pratique

Apprendre à faire

Planifier une tâche récurrente avec un timer systemd

$ dsoxlab run l3-scheduling-timers

Environnement : VM·Durée : ~25 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start l3-scheduling-timers vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run l3-scheduling-timers
dsoxlab check l3-scheduling-timers

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• Un timer systemd = un fichier .timer + un fichier .service (même nom par convention)
• OnCalendar déclenche à un moment précis, les timers monotones (OnBootSec, OnUnitActiveSec) après un délai
• Persistent=true rattrape les exécutions manquées, activez-le systématiquement pour les tâches de maintenance
• systemd-analyze calendar vérifie la syntaxe avant de déployer
• Les timers offrent la journalisation (journalctl), le sandboxing et les dépendances, absents de cron
• Les timers utilisateur se placent dans ~/.config/systemd/user/ ; loginctl enable-linger les fait tourner même sans session ouverte
• Pas de commentaire en fin de ligne dans une unité : le réglage serait ignoré, systemd-analyze verify le révèle
• cron et les timers coexistent, choisissez selon la complexité et les besoins de journalisation

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →