Cron ou un timer systemd ?

Les deux lancent quelque chose à intervalles réguliers. La différence apparaît quand une tâche échoue, quand elle dure longtemps, ou quand la machine était éteinte au moment prévu.

Cron et ses deux pièges

crontab -e
# m h dom mon dow  command
15 3 * * *  /usr/bin/php /var/www/site/cron.php >> /var/log/site-cron.log 2>&1

• L'environnement est presque vide. PATH est minimal et votre profil de shell n'est pas lu : une commande qui marche quand vous la tapez échoue ici. Utilisez des chemins absolus.
• La sortie est un courrier, pas un journal. Sans la redirection ci-dessus, elle part dans une boîte locale que personne ne lit, et la tâche semble s'être exécutée en silence.

Si une tâche cron ne semble jamais s'exécuter du tout, la liste de Les tâches cron qui ne s'exécutent jamais couvre le reste.

Un timer, et ce qu'il apporte

# /etc/systemd/system/site-cron.service
[Unit]
Description=Site maintenance

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/var/www/site
ExecStart=/usr/bin/php cron.php

# /etc/systemd/system/site-cron.timer
[Unit]
Description=Run site maintenance nightly

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

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now site-cron.timer
systemctl list-timers --all
journalctl -u site-cron -n 50

Ce que le timer vous donne

• Des journaux dans le journal système, avec le code de sortie, pour chaque exécution.
• Pas de chevauchement — une exécution encore en cours au moment de la suivante ne lance pas une seconde copie.
• Persistent=true — une exécution manquée pendant que la machine était éteinte a lieu au démarrage suivant.
• RandomizedDelaySec — une flotte de serveurs ne frappe pas la même API tous ensemble à 03:15:00 pile.

Lequel choisir

Une tâche d'une ligne sur une machine : cron, et n'y réfléchissez pas trop. Tout ce dont vous devez voir l'historique, tout ce qui ne doit pas s'exécuter deux fois, et tout ce qui compte si on le rate : un timer.