Décoder une expression cron
Analyseur d’expressions cron explique une planification en toutes lettres et liste ses dix prochaines exécutions, dans votre navigateur. Il énonce la règle qui piège presque tout le monde : quand le jour du mois et le jour de la semaine sont tous deux restreints, cron les combine avec un OU — 0 0 13 * 5 se déclenche donc le 13 ou n’importe quel vendredi, et pas le vendredi 13.
Comment fonctionne Décoder une expression cron ?
Cron tient en cinq nombres, et pourtant il est régulièrement mal lu. Trois points expliquent presque toutes ces erreurs.
Les deux champs de jour sont combinés par OU, pas par ET
Toutes les autres paires de champs se croisent : 0 9 * 6 *, c’est neuf heures en juin, croisé entre heure et mois. Les champs de jour, non. Quand le jour du mois et le jour de la semaine sont tous deux restreints, la tâche s’exécute si l’un ou l’autre correspond. Ainsi 0 0 13 * 5 se déclenche le 13 de chaque mois et chaque vendredi — environ cinq fois par mois, pas une ou deux fois par an. C’est dans POSIX et dans la page de manuel de Vixie cron, et cela surprend encore du monde ; voilà pourquoi l’explication ici le dit clairement au lieu de décrire les champs séparément.
Quand l’un des deux est *, l’autre décide seul, et 0 0 * * 5 est donc simplement chaque vendredi.
Le calcul de la prochaine exécution est une recherche qui doit se terminer
0 0 31 2 * demande minuit le 31 février, qui n’arrive jamais. Un balayage minute par minute prend 2.6 millions d’itérations avant d’atteindre une limite d’un an et d’abandonner ; un balayage sans limite n’abandonne jamais du tout. La recherche ici saute par la plus grande unité qu’elle peut écarter — un mois qui ne correspond pas avance au premier du mois suivant, au lieu de passer par ses jours — de sorte qu’une planification impossible est prouvée impossible en quelques centaines d’étapes.
Tout est ici en UTC, c’est délibéré
Une tâche cron programmée dans un fuseau avec heure d’été s’exécute réellement deux fois une nuit par an, et pas du tout une autre : quand l’horloge recule, 01:30 arrive deux fois ; quand elle avance, 02:30 n’arrive pas. Les différentes implémentations de cron gèrent cela différemment, et certaines ne le gèrent pas du tout. Calculer en UTC et le dire est honnête ; appliquer en silence le fuseau de votre navigateur produirait des heures d’apparence fiable, fausses deux fois par an.
Nombre de champs et dialectes
Cinq champs, c’est le cron Unix standard. Six signifie généralement les secondes en premier, ce que font Quartz, Spring et node-cron — quoique quelques ordonnanceurs placent une année à la fin à la place, ce qui est réellement ambigu et résolu ici en faveur des secondes. Sept champs, c’est Quartz avec les deux. L’analyseur accepte les noms de mois et de jours, les plages qui bouclent comme FRI-MON et 22-2, ? comme joker, 0 et 7 tous deux pour le dimanche, et la famille de raccourcis @daily.
@reboot est reconnu et expliqué plutôt qu’analysé : il n’a pas de planification, donc il n’y a aucune prochaine exécution à calculer.
Expression
0 0 13 * 5
Explication
At 00:00, on day 13 of the month OR on Friday — cron ORs these two fields rather than intersecting them, so this is not "Friday the 13th". UTC.
Quelles options et quels cas limites Décoder une expression cron prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| * | joker | toutes les valeurs | Dans un champ de jour, cela signifie aussi 'laisser l’autre champ de jour décider', ce qui rend la règle OR gérable. |
| */n | pas | — | Toutes les n-ièmes valeurs à partir du minimum du champ. */15 en minutes donne 0, 15, 30, 45 — pas 'toutes les 15 minutes à partir de maintenant'. |
| a-b | intervalle | — | Inclusif. Un intervalle circulaire est accepté : 22-2 en heures donne 22, 23, 0, 1, 2, et VEN-DIM est le week-end. |
| a,b,c | liste | — | Toute combinaison de valeurs simples, d’intervalles et de pas, séparés par des virgules. |
| n/m | pas à partir de n | — | 5/6 en heures donne 5, 11, 17, 23 — de 5 au maximum, par pas de 6. |
| Noms | JAN-DÉC, DIM-SAM | accepté | Insensible à la casse, et utilisable dans les intervalles : JAN-MAR, DIM-VEN. |
| 0 et 7 | Dimanche | les deux | Toutes les implémentations acceptent les deux, et presque aucune documentation ne mentionne cela au même endroit que quoi que ce soit d’autre. |
| ? | joker | Quartz | Traité comme *. Quartz l’utilise pour signifier 'aucune valeur spécifique' dans un champ de jour. |
| Nombre de champs | 5, 6 ou 7 | 5 | Cinq est le standard Unix. Six se lit comme secondes-d’abord, ce que Quartz, Spring et node-cron signifient. Sept est Quartz avec une année. |
| @daily et ses amis | raccourci | développé | @yearly @annually @monthly @weekly @daily @midnight @hourly. @reboot n’a pas de schedule et est expliqué plutôt que parsé. |
| Fuseau horaire | UTC | toujours | Un schedule en temps local s’exécute réellement deux fois une nuit par an et pas du tout une autre nuit. Calculer en UTC et le dire est préférable à produire des heures locales faussement certaines. |
Questions fréquentes
0 0 13 * 5 s’exécute-t-il le vendredi 13 ?
Non — il s’exécute le 13 de chaque mois et chaque vendredi. Cron combine les deux champs de jour par OU au lieu de les croiser, ce qui est l’inverse de ce que fait toute autre paire de champs, et c’est le malentendu cron le plus répandu. Pour le vendredi 13 précisément, il faut une restriction sur le jour du mois plus une vérification à l’intérieur de la tâche elle-même ; cron ne peut pas exprimer ce croisement.
Que signifie réellement */15 ?
Toute valeur divisible par 15 dans le champ, en partant du minimum du champ — pour les minutes, ce sont donc 0, 15, 30 et 45. Ce n’est pas « toutes les quinze minutes à partir de mon déploiement ». La distinction compte quand on le combine avec une restriction d’heure : 0 */2 * * * s’exécute à 00:00, 02:00, 04:00 et ainsi de suite, pas deux heures après chaque exécution précédente.
Pourquoi toutes les heures sont-elles en UTC ?
Parce qu’une planification en heure locale est réellement ambiguë deux fois par an. Quand l’horloge recule, 01:30 se produit deux fois et certaines implémentations exécutent la tâche deux fois ; quand elle avance, 02:30 ne se produit pas et certaines implémentations la sautent entièrement. Le comportement varie d’une implémentation de cron à l’autre. Afficher UTC et le dire est honnête ; appliquer en silence le fuseau de votre navigateur produirait des heures d’apparence fiable mais fausses deux jours par an.
Cinq, six ou sept champs ?
Cinq pour le cron Unix, crontab et la plupart des ordonnanceurs de CI. Six pour Quartz, @Scheduled de Spring et node-cron, où le champ supplémentaire vient en premier et contient les secondes. Sept pour Quartz avec une année à la fin. Six champs est réellement ambigu — quelques ordonnanceurs mettent l’année à la fin à la place — et cet analyseur le lit secondes en premier, de loin le plus courant.
Pourquoi mon expression n’affiche-t-elle aucune exécution ?
Elle ne peut jamais se déclencher. La cause habituelle est une combinaison jour du mois et mois qui n’existe pas — 0 0 31 2 * demande un 31 février — ou une restriction d’année déjà passée. La recherche regarde cinq ans en avance avant de conclure cela, donc une liste vide signifie réellement impossible et pas simplement lointain.
Mon expression est-elle envoyée ?
Non. L’analyse et la recherche de la prochaine exécution s’exécutent toutes deux dans votre navigateur. Une expression cron n’est pas un secret, mais elle décrit le rythme de votre infrastructure, et il n’y a aucune raison pour que cela parvienne à un serveur qui n’en a aucun usage.