Tâches planifiées : crontab et timers systemd

Planifier une tâche, c'est demander au système de lancer une commande ou un script automatiquement, à heure fixe ou à intervalle régulier : une sauvegarde chaque nuit, une purge chaque semaine, un rapport chaque lundi. Sous Linux, deux outils le font : cron, avec sa crontab et sa syntaxe en cinq champs, et les timers de systemd. Ce chapitre explique la syntaxe de la crontab avec des exemples, les pièges classiques, l'écriture d'un timer et le choix entre les deux.

La syntaxe de la crontab

Le démon cron lit chaque minute les tables de tâches et lance celles dont l'heure est venue. Une ligne de crontab compte cinq champs de date, puis la commande :

Les raccourcis @hourly, @daily, @weekly, @monthly existent aussi (@daily vaut 0 0 * * *).

Où écrire les tâches

crontab -l affiche la table, crontab -e l'ouvre dans l'éditeur et la vérifie à l'enregistrement. crontab -r la supprime sans confirmation : les touches e et r sont voisines.

Chez Sorbier, l'archivage nocturne de srv-journaux est une tâche système, dans son propre fichier :

# /etc/cron.d/archive-journaux
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
MAILTO=informatique@sorbier.example

# Archiver les journaux distants de plus de 30 jours, chaque nuit à 2 h 30
30 2 * * *  root  /usr/local/bin/archive-journaux >> /var/log/archive-journaux.log 2>&1

Sur Debian, les scripts des dossiers cron.daily et suivants sont lancés par run-parts depuis /etc/crontab : chaque jour à 6 h 25, chaque dimanche à 6 h 47, le 1er du mois à 6 h 52. Le paquet cron est présent sur une installation Debian standard ; s'il manque (image cloud, conteneur), sudo apt install cron, et systemctl status cron vérifie qu'il tourne. Son journal se lit avec journalctl -u cron.

Les pièges de cron

Une commande qui marche dans ton terminal et échoue dans cron, c'est presque toujours l'un de ces cinq pièges :

1. Le PATH réduit. Cron lance les commandes avec un PATH minimal (/usr/bin:/bin). Une commande de /usr/sbin ou de /usr/local/bin n'est pas trouvée. Écris les chemins complets, ou fixe PATH en tête du fichier.
2. Pas de terminal ni de variables de session. Aucune variable de ton .bashrc, aucun agent SSH, et le dossier courant est le dossier personnel du compte. Utilise des chemins absolus partout.
3. Le % a un sens spécial dans une crontab (fin de commande, retour à la ligne) : date +%F doit s'écrire date +\%F.
4. La sortie perdue. Ce que la commande affiche est envoyé par courriel à MAILTO, ou perdu si aucun agent de messagerie n'est configuré. Redirige vers un fichier (>> /var/log/… 2>&1) pour garder une trace des erreurs.
5. Les noms de scripts dans cron.daily. run-parts ignore les fichiers dont le nom contient un point : un script sauvegarde.sh déposé dans /etc/cron.daily/ n'est jamais exécuté. Nomme-le sauvegarde, rends-le exécutable, et vérifie avec run-parts --test /etc/cron.daily.

Les timers systemd

Un timer systemd est une unité .timer qui démarre une unité .service à une date donnée. Il faut deux fichiers, mais on gagne beaucoup : les journaux de chaque exécution dans journalctl, le rattrapage des exécutions manquées pendant un arrêt, un délai aléatoire pour ne pas lancer tout le parc à la même seconde, et toutes les protections d'une unité de service. Debian l'utilise déjà pour ses propres tâches (apt-daily.timer, logrotate.timer, fstrim.timer).

Le même archivage, en timer :

# /etc/systemd/system/archive-journaux.service
[Unit]
Description=Archivage des journaux distants de plus de 30 jours

[Service]
Type=oneshot
ExecStart=/usr/local/bin/archive-journaux
Nice=10

# /etc/systemd/system/archive-journaux.timer
[Unit]
Description=Archivage nocturne des journaux distants

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=10min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now archive-journaux.timer    # on active le timer, pas le service
systemctl list-timers archive-journaux.timer          # prochaine et dernière exécution
sudo systemctl start archive-journaux.service         # lancer une fois tout de suite, pour tester
journalctl -u archive-journaux.service                # la sortie de chaque exécution

Quelques valeurs d'OnCalendar :

systemd-analyze calendar "Mon..Fri 19:00" vérifie une expression et affiche la prochaine échéance : un réflexe avant d'enregistrer un timer.

cron ou timer ?

Pour une tâche ponctuelle (redémarrer à 4 h cette nuit), l'outil est at (paquet at) : echo "systemctl reboot" | sudo at 04:00, atq pour la file, atrm pour annuler. Sans at, sudo systemd-run --on-calendar="2026-11-05 04:00" systemctl reboot crée un timer temporaire.

Le contenu des scripts eux-mêmes (variables, conditions, boucles, codes de retour) est l'objet du cours Scripts PowerShell et Bash.

Exercices

[Unit]
Description=Purge hebdomadaire des exports

[Service]
Type=oneshot
ExecStart=/usr/local/bin/purge-exports

[Unit]
Description=Purge des exports chaque dimanche à 3 h 15

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

[Install]
WantedBy=timers.target