Traducteur d’expression cron :
que fait cette ligne ?

Chaque minute de chaque heure, chaque jour — 1 440 exécutions par jour, 525 600 par an. Les cinq champs sont tous des jokers, donc rien n’est restreint. C’est la bonne planification pour un ping de santé peu coûteux, et la mauvaise pour presque tout le reste. Héritée devant un script coûteux, c’est la première ligne à remettre en question.

Une valeur sur 5 dans ce champ, comptée depuis son minimum. Dans le champ des minutes, */5 se déclenche à :00, :05, :10 … :55 — 12 fois par heure, pile sur les graduations de l’horloge. Cela ne veut pas dire « 5 minutes après la dernière exécution » : cron compare des valeurs d’horloge. Donc */7 donne :00, :07 … :56 puis :00 à nouveau — un écart de 4 minutes au début de chaque heure.

Chaque jour à minuit, heure du serveur — minute 0 de l’heure 0, n’importe quelle date, n’importe quel mois, n’importe quel jour de la semaine. C’est exactement la planification qu’abrège @daily. « Minuit » est le minuit du serveur, et les nuits de changement d’heure, un serveur réglé en heure locale peut le sauter ou le répéter.

Identiques. Les raccourcis correspondent exactement : @hourly = 0 * * * *, @daily et @midnight = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. L’exception, c’est @reboot — ce n’est pas une planification du tout, il se déclenche au démarrage du démon cron. Ce traducteur développe les raccourcis pour que vous voyiez toujours les cinq champs en dessous.

Parce qu’elle ne vient pas d’un crontab. Quartz (Jenkins, Spring), certains ordonnanceurs cloud et quelques bibliothèques cron placent un champ secondes en premier, ce qui en fait six — ou sept avec une année à la fin. Un crontab refusera de l’installer. Si le champ des secondes vaut 0, retirez-le : les cinq champs restants se lisent alors généralement comme du POSIX. S’il vaut autre chose, la planification se déclenche en dessous de la minute, et le cron classique ne sait tout simplement pas exprimer cela.

C’est du Quartz pour « aucune valeur précisée ». Quartz exige que l’un des deux champs de jour, et un seul, soit désactivé — c’est lui qui reçoit le point d’interrogation. Le cron POSIX n’a pas cette règle, ni de ? d’ailleurs — un simple * suffit. Quand les deux champs de jour sont restreints, cron s’exécute sur l’union des deux. Collez un ? dans un crontab et la ligne est rejetée.

Oui. Collez 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 et le lecteur prend les cinq champs de planification, les traduit, et nomme le reste de la ligne comme la partie qu’il a ignorée. Il lit aussi la forme /etc/crontab, où un nom d’utilisateur se place entre la planification et la commande. Ce qu’il ne fera pas, c’est deviner une ligne à six champs : un champ des secondes en tête signifie Quartz, pas crontab, et c’est un langage différent.

Collez l’expression ci-dessus. La vue de résultat liste les dix prochaines exécutions sous forme de dates concrètes, calculées par un véritable analyseur, dans le fuseau horaire de votre navigateur. Le crontab, lui, s’exécute sur l’horloge du serveur : si la machine tourne en UTC et pas vous, toute la liste se décale de votre écart horaire. Rien ne vous dit en revanche qu’une exécution a réussi — cron ne journalise jamais que son démarrage.