Cron ou timers systemd : cron lit des lignes, les timers exécutent des unités

LES DEUX HORLOGES

Le même job — sauvegarde nocturne à 03:30 — sur les deux horloges, et ce que chacune laisse derrière elle :

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

# foo.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
# foo.service — the job itself

le verdict des plannings : les cinq champs de cron sont l'incumbent compact ; OnCalendar est plus bavard mais strictement plus expressif — Mon..Fri 09..17:00:00 tient en une ligne, et RandomizedDelaySec empêche mille machines de marteler un seul serveur

ces horloges re-horodatent d'après les propres commandes du dossier — elles ne peuvent pas lire le journal de votre machine ; où est réellement votre journal : sections 04 et 05.

LES ÉCARTS PRATIQUES

• Logging : les timers loguent stdout/stderr dans le journal, par unité ; cron au mieux met un courriel à l'utilisateur local.
• Runs manqués : un timer avec Persistent=true tourne une fois au boot si son planning a été manqué ; cron saute sans un mot.
• Dépendances : les timers savent attendre network-online.target ou des points de montage ; cron, il faut bricoler la logique de retry à la main dans le script.
• Syntaxe : cron, une ligne ; un timer, deux fichiers. C'est tout le coût du basculement.
• Option monotonic: OnBootSec=15min — les changements d'horloge murale ne peuvent pas le troubler.

04TESTER UN TIMER SANS ATTENDRE

Trois commandes répondent à tout — lister ce qui est planifié et quand ça déclenchera, tourner le job à la main exactement comme le timer le ferait, puis lire ses logs :

systemctl list-timers --all                 # every timer, next + last run
sudo systemctl start backup.service         # fire the job now, same unit as the timer
journalctl -u backup.service -f             # watch its output live

Notez la répartition : systemctl start backup.timer arme le planning ; le service est le job. Si list-timers montre votre timer, systemctl status backup.service est vert, et le journal montre votre sortie, toute la chaîne marche.

verify: systemctl list-timers --all → votre timer, dernière et prochaine exécutions listées

05LANCER UN JOB CRON À LA MAIN

Les jobs cron tournent avec un environnement dépouillé, voilà pourquoi « ça marche dans mon shell, ça rate dans cron » est un genre de bug à part entière. Pour reproduire cron fidèlement, lancez la commande via sh avec l'environnement que cron utiliserait :

crontab -l                                  # confirm the exact line
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # did cron even fire it? (Debian/Ubuntu)
journalctl -u cron -n 20                    # same, on systemd distros

Cette env -i ligne est le test manuel honnête : un environnement nu avec le PATH par défaut de cron. Les deux classiques de cron — un PATH nu et un % non quoté (cron le traite comme un retour à la ligne) — apparaissent immédiatement dans ce test.

verify: journalctl -u cron -n 20 → l'entrée CRON de votre commande

« MON TIMER NE SE DÉCLENCHE PAS »

Un timer qui semble mort a d'ordinaire un service qui échoue instantanément. Quatre causes, dans l'ordre où les vérifier :

1. Les noms du service et du timer ne correspondent pas. foo.timer déclenche foo.service — une coquille ou une unité renommée, et le timer « tourne » dans le vide. systemctl cat foo.timer montre exactement ce qu'il vise.
2. Édité mais pas rechargé. Après modification d'un fichier d'unité : sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Sans ça, votre nouveau planning n'est pas vivant.
3. Mauvaise commande de statut. systemctl status foo.timer montre toujours active même au repos — lisez list-timers à la place.
4. Le service qu'il déclenche échoue instantanément. journalctl -u foo.service --since -1h montre le crash que list-timers cache.

verify: journalctl -u foo.service --since -1h → le crash que list-timers cache

LA TABLE DE DÉCISION

Règles de pouce : livrer un job sur votre propre machine systemd → timer. Rappel perso rapide, ou une machine que vous n'avez pas installée → cron. Tout ce qui a des dépendances, des retries, ou le besoin de savoir si ça a vraiment tourné → timer, toujours. Le patron classique — une sauvegarde rsync nocturne sous un timer avec Persistent=true — garantit que la sauvegarde arrive même si la machine dormait à la minute prévue, ce que cron ne peut simplement pas offrir.

fin des deux horloges · rien n'a été téléchargé · tout est local