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
Section intitulée « 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 ?
Section intitulée « 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
journalctlpour diagnostiquer les erreurs d’un job planifié
Les timers actifs
Section intitulée « Les timers actifs »Pour voir tous les timers du système :
systemctl list-timers --allNEXT LEFT LAST PASSED UNIT ACTIVATESSat 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.serviceSat 2026-06-28 14:19:18 1h 28min left Sat 2026-06-28 06:32:32 6h ago apt-daily.timer apt-daily.serviceSun 2026-06-29 00:00:00 11h left Sat 2026-06-28 00:00:14 12h ago dpkg-db-backup.timer dpkg-db-backup.serviceSun 2026-06-29 00:00:00 11h left Sat 2026-06-28 00:00:14 12h ago logrotate.timer logrotate.serviceChaque 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é |
Deux types de timers
Section intitulée « Deux types de timers »Timer calendaire (OnCalendar)
Section intitulée « 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
Section intitulée « Timer monotone »Déclenché après un délai relatif à un événement (démarrage, dernière exécution, activation) :
[Timer]OnBootSec=15minOnUnitActiveSec=1hCe 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é |
Analyser un timer existant
Section intitulée « 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:00RandomizedDelaySec=12hPersistent=true
[Install]WantedBy=timers.targetDécryptage
Section intitulée « 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 |
# Voir le service associésystemctl cat apt-daily.serviceSyntaxe OnCalendar
Section intitulée « Syntaxe OnCalendar »La syntaxe OnCalendar est plus expressive que cron :
DayOfWeek Year-Month-Day Hour:Minute:SecondExemples courants
Section intitulée « 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 |
Valider avec systemd-analyze
Section intitulée « 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:00Normalized 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 occurrencessystemd-analyze calendar --iterations=5 'daily'Créer un timer personnalisé
Section intitulée « Créer un timer personnalisé »Créons un timer qui nettoie /tmp chaque jour à 4 h.
-
Créer le service
Fenêtre de terminal sudo systemctl edit --full --force cleanup-tmp.service[Unit]Description=Nettoyage des fichiers temporaires de plus de 7 jours[Service]Type=oneshotExecStart=/usr/bin/find /tmp -type f -mtime +7 -delete -
Créer le timer
Fenêtre de terminal sudo systemctl edit --full --force cleanup-tmp.timer[Unit]Description=Timer quotidien de nettoyage /tmp[Timer]OnCalendar=*-*-* 04:00:00Persistent=true[Install]WantedBy=timers.target -
Activer et démarrer le timer
Fenêtre de terminal sudo systemctl daemon-reloadsudo systemctl enable --now cleanup-tmp.timer -
Vérifier le timer
Fenêtre de terminal systemctl status cleanup-tmp.timer● cleanup-tmp.timer - Timer quotidien de nettoyage /tmpLoaded: loaded (/etc/systemd/system/cleanup-tmp.timer; enabled)Active: active (waiting)Trigger: Sun 2026-06-29 04:00:00 CEST; 15h left -
Tester le service manuellement
Fenêtre de terminal sudo systemctl start cleanup-tmp.servicesystemctl status cleanup-tmp.service
Timer utilisateur (sans sudo)
Section intitulée « 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 servicecat > ~/.config/systemd/user/mon-backup.service << 'EOF'[Unit]Description=Sauvegarde personnelle
[Service]Type=oneshotExecStart=/home/%u/scripts/backup.shEOF
# Créer le timercat > ~/.config/systemd/user/mon-backup.timer << 'EOF'[Unit]Description=Timer de sauvegarde personnelle
[Timer]OnCalendar=*-*-* 20:00:00Persistent=true
[Install]WantedBy=timers.targetEOF
# Activersystemctl --user daemon-reloadsystemctl --user enable --now mon-backup.timersystemctl --user list-timersOptions avancées
Section intitulée « Options avancées »AccuracySec
Section intitulée « 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:00AccuracySec=1s # Exécution précise à la secondeUn timer de logrotate typique utilise AccuracySec=1h — la précision au jour suffit.
RandomizedDelaySec
Section intitulée « RandomizedDelaySec »Ajoute un délai aléatoire pour éviter que toutes les machines lancent la même tâche simultanément :
[Timer]OnCalendar=dailyRandomizedDelaySec=4h # Étalement sur 4 heuresPersistent
Section intitulée « 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=dailyPersistent=truecron vs timers systemd
Section intitulée « 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 |
Dépannage
Section intitulée « 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 |
# Diagnostiquer un timersystemctl status mon-job.timerjournalctl -u mon-job.service --since today
# Vérifier la prochaine exécutionsystemd-analyze calendar 'OnCalendar expression'
# Forcer un déclenchement immédiatsudo systemctl start mon-job.serviceÀ retenir
Section intitulée « À 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écessitentloginctl enable-linger - cron et les timers coexistent — choisissez selon la complexité et les besoins de journalisation