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

Les timers systemd font partie des objectifs RHCSA. Vous devez savoir créer un timer, l'activer et vérifier son fonctionnement. Pour LFCS, la connaissance de cron et des timers est attendue.

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 18:19:57     5h 29min left Sat 2026-06-28 06:44:19     6h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Sat 2026-06-28 14:19:18     1h 28min left Sat 2026-06-28 06:32:32     6h ago       apt-daily.timer              apt-daily.service
Sun 2026-06-29 00:00:00     11h left      Sat 2026-06-28 00:00:14     12h ago      dpkg-db-backup.timer         dpkg-db-backup.service
Sun 2026-06-29 00:00:00     11h left      Sat 2026-06-28 00:00:14     12h ago      logrotate.timer              logrotate.service

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

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

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. Une erreur de syntaxe dans OnCalendar est silencieuse, le timer ne se déclenchera simplement pas.

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

   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 :

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=/home/%u/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

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 :

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

Un timer de logrotate typique utilise AccuracySec=1h, la précision au jour suffit.

RandomizedDelaySec

Ajoute un délai aléatoire pour éviter que toutes les machines lancent la même tâche simultanément :

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

Persistent

Persistent=true rattrape les exécutions manquées. Si la machine était éteinte à l'heure prévue, le timer se déclenche immédiatement au prochain démarrage :

[Timer]
OnCalendar=daily
Persistent=true

Toujours activer Persistent

Pour les tâches de maintenance (sauvegardes, nettoyage, rotation), activez systématiquement Persistent=true. C'est le principal avantage des timers sur cron.

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
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

Symptôme	Cause probable	Solution
Timer n'apparaît pas dans list-timers	Timer non activé	systemctl enable --now mon.timer
Timer actif mais service jamais déclenché	Erreur de syntaxe OnCalendar	Vérifier avec systemd-analyze calendar
Service échoue silencieusement	Erreur dans ExecStart	journalctl -u mon-service.service
Timer déclenché en retard	AccuracySec trop large	Réduire AccuracySec=1min
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
systemd-analyze calendar 'OnCalendar expression'

# 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 pratique

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

$ dsoxlab run l3-scheduling-timers

Environnement : VM·Durée : ~25 min

Validé : 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.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

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.

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

À 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/ et nécessitent loginctl enable-linger
• cron et les timers coexistent, choisissez selon la complexité et les besoins de journalisation

Pour aller plus loin

• Gestion des services avec systemd : Comprendre les unités, les états et systemctl.
• Journaux système avec journald : Exploiter journalctl pour diagnostiquer vos timers.
• Rotation des logs avec logrotate : Un timer systemd gère déjà logrotate sur votre système.

×

📖 Voir la documentation →