Planification des tâches sous Linux : comparaison entre cron et systemd timer

Planification des tâches sous Linux : comparaison entre cron et systemd timer

Dans la gestion des systèmes Linux, le moment d’exécution d’une tâche est aussi crucial que ce qui est exécuté. Le compagnon le plus ancien est cron, tandis que la plupart des distributions récentes privilégient systemd timer. Dans cet article, nous comparons les deux solutions et indiquons dans quelles situations chacune est préférable.

1. Pourquoi comparer cron et systemd timer ?

La plupart des serveurs Linux rencontrent ces besoins :

• Sauvegarde quotidienne à 3 h du matin
• Script de vérification de santé toutes les 5 minutes
• Compression et archivage des logs chaque dimanche
• Initialisation qui doit s’exécuter une seule fois, 1 minute après le démarrage

Traditionnellement, tout était géré par cron. Aujourd’hui, de nombreuses distributions utilisent systemd comme système d’initialisation, ce qui fait de son timer unit une alternative puissante.

2. Concepts de base de cron

2.1 Qu’est‑ce que cron ?

cron est un planificateur Unix/Linux ancien. Il exécute des commandes selon un horaire défini, et la configuration se fait principalement via le fichier crontab.

2.2 Où se trouve la configuration de cron ?

• Système : /etc/crontab, /etc/cron.d/
• Utilisateur : édité avec crontab -e

Par exemple, pour lancer un script de sauvegarde chaque jour à 3 h du matin :

0 3 * * * /usr/local/bin/backup.sh

Les champs signifient :

min  hour  day  month  weekday  command
0    3     *    *      *        /usr/local/bin/backup.sh

2.3 Avantages de cron

• Outil éprouvé et fiable
• Concept identique sur la plupart des systèmes Unix/Linux
• Syntaxe simple et nombreux exemples
• Fonctionne même sur les systèmes sans systemd

2.4 Limites de cron

• Séparé des services : difficile de savoir à quel service une tâche appartient
• Vérification d’état/​logs compliquée (syslog, mail, etc.)
• Gestion des dépendances faible (ex. : service doit être démarré avant)
• Planification relative (« 5 minutes après le démarrage ») peu claire

3. Concepts de base de systemd timer

3.1 Qu’est‑ce que systemd timer ?

systemd timer est l’unit de minuterie de systemd. Il déclenche un autre unit de service selon des conditions (heure, temps depuis le démarrage, etc.).

En pratique, on travaille toujours en paire :

• myjob.service : définit la tâche à exécuter
• myjob.timer : définit quand la tâche doit être lancée

3.2 Exemple de service + timer

Pour exécuter une sauvegarde chaque jour à 3 h du matin :

(1) Unité de service : /etc/systemd/system/backup.service

[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

(2) Unité de minuterie : /etc/systemd/system/backup.timer

[Unit]
Description=Run daily backup at 3:00

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

[Install]
WantedBy=timers.target

Activation :

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

3.3 Avantages de systemd timer

• Lien clair avec le service : on sait exactement quel service est déclenché
• Gestion des logs simplifiée : journalctl -u backup.service
• Conditions de déclenchement flexibles :
• OnCalendar= : expression horaire similaire à cron
• OnBootSec= : X secondes après le démarrage
• OnUnitActiveSec= / OnUnitInactiveSec= : X secondes après la dernière exécution
• Gestion des dépendances : After=network-online.target, Requires=…
• Intégration avec l’écosystème systemd : systemctl list-timers, systemctl status

3.4 Inconvénients de systemd timer

• Courbe d’apprentissage plus élevée (service + timer)
• Dépendance à systemd : pas utilisable sur les systèmes très anciens ou non‑systemd
• Pour une tâche simple d’une seule ligne, peut sembler excessif

4. Comparaison fonctionnelle

4.1 Tableau comparatif

5. Illustrations pratiques

5.1 Sauvegarde quotidienne à 3 h : cron vs timer

Version cron

0 3 * * * /usr/local/bin/backup.sh

Version systemd timer

# backup.service
[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# backup.timer
[Unit]
Description=Run daily backup at 3:00

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

[Install]
WantedBy=timers.target

5.2 Exécution unique 5 minutes après le démarrage

Avec cron, on recourt souvent à des astuces (@reboot + sleep, rc.local, etc.).

Implémentation systemd timer

# init-job.service
[Unit]
Description=Run custom init job after boot

[Service]
Type=oneshot
ExecStart=/usr/local/bin/init-job.sh

# init-job.timer
[Unit]
Description=Run init job 5 minutes after boot

[Timer]
OnBootSec=5min
AccuracySec=1min

[Install]
WantedBy=timers.target

Ainsi, 5 minutes après le démarrage, init-job.service s’exécute une seule fois.

6. Quand choisir quoi ?

6.1 Quand rester avec cron

• Vous avez déjà de nombreuses tâches cron fonctionnelles
• Vous n’avez pas besoin d’une intégration poussée avec systemd
• Vous gérez un petit serveur avec seulement quelques tâches récurrentes
• Vous devez supporter des environnements non‑systemd (certaines conteneurs, BSD, très anciens OS)

6.2 Quand opter pour systemd timer

• Vos services sont déjà gérés par systemd
• Vous souhaitez centraliser logs et état via journalctl
• Vous avez besoin de déclencheurs relatifs (« 5 minutes après le démarrage », « X minutes après la dernière exécution »)
• Vous avez des dépendances complexes (ex. : démarrer après le réseau ou un service spécifique)
• Vous travaillez dans un pipeline CI/CD ou un environnement de production où l’observabilité est cruciale

7. Conseils pour migrer des tâches cron vers systemd timer

1. Lister les tâches cron actuelles * crontab -l * Vérifier /etc/crontab et /etc/cron.d/*
2. Décomposer chaque tâche en service + timer * Service : ce qui doit être exécuté * Timer : quand l’exécuter
3. Convertir la syntaxe horaire * 0 3 * * * → OnCalendar=*-*-* 03:00:00 * */5 * * * * → OnCalendar=*:0/5
4. Tester * systemctl start myjob.service pour vérifier le service * systemctl start myjob.timer puis systemctl list-timers pour confirmer l’horaire
5. Désactiver le cron original * Une fois le timer stable, commenter ou supprimer la ligne cron correspondante

8. Conclusion : coexistence possible

En résumé :

• cron reste un planificateur simple et portable
• systemd timer offre une gestion orientée service, une observabilité accrue et des déclencheurs flexibles

Il n’existe pas de « bonne » réponse unique. Si vous créez de nouvelles tâches ou si elles sont étroitement liées à un service, privilégiez systemd timer. Pour des tâches simples déjà en place, cron peut rester sans problème.