Crond calendrier de décalage de cinq minutes

Le champ d'entrée de minute pour crontab accepte un opérateur "par incréments" qui est un peu déroutant car il ressemble à un opérateur "divisé par" mathématique mais ne l'est pas. Vous verrez le plus souvent utilisé quelque chose comme ce qui suit. Notez que cela ne trouve pas les nombres divisibles par cinq mais prend plutôt chaque cinquième élément d'un ensemble :

 */5 * * * * commande

Cela indique à cron de faire correspondre chaque cinquième élément (/5) de l'ensemble des minutes 0-59 (*) mais vous pouvez changer l'ensemble comme ceci :

 1-59/5 * * * * commande

Cela prendrait chaque cinquième élément de l'ensemble 1-59, exécutant votre commande aux minutes 6, 11, 16, etc.

Si vous avez besoin de décalages plus fins que d'une minute, vous pouvez le faire en utilisant la commande sleep comme partie de votre crontab comme ceci :

 */5 * * * * sleep 15 && commande

Cela exécuterait votre tâche toutes les cinq minutes, mais la commande ne démarrerait pas réellement avant 15 secondes après la minute. Pour les tâches de courte durée où être quelques secondes après quelque chose d'autre fait toute la différence mais que vous ne voulez pas être en retard d'une minute complète, c'est une astuce assez simple.

Vous pouvez indiquer un décalage horaire avec le symbole +. Par exemple, pour s'exécuter à :01, :06, :11, :16 [...], créez une tâche comme

*/5+1 * * * * commande

Cela a fonctionné pour moi :

1/5 * ? * * *

Où 1 est le décalage en minutes. Donc si vous voulez un décalage de trois minutes :

3/5 * ? * * *

Cela fonctionne dans les paramètres de planification AWS

Ceci est un problème XY. Décaler cron par rapport à des intervalles d'heure entière, ou des fractions communes de celles-ci, peut être généralement utile pour réduire les processus coïncidants, mais cette question déclare explicitement que le décalage vise à résoudre une dépendance. Bien que nous soyons informés que le script 2 doit s'exécuter indépendamment de l'achèvement du script 1, il ne devrait certainement pas essayer de s'exécuter alors que le script 1 est en train de mettre à jour l'ensemble de données partagé. Utiliser le temps seul pour imposer une séquence crée un retard inutile entre les deux au mieux, et une condition de course au pire.

Il est préférable de les mettre dans la même ligne de travail cron pour créer la dépendance chronologique :

*/5 * * * * /chemin/vers/script1; /chemin/vers/script2

Le point-virgule sépare les commandes mais garantit qu'elles s'exécuteront toutes indépendamment du statut de sortie précédent.

Dans les cas où la deuxième commande doit s'exécuter seulement si la première commande est réussie, modifiez-la comme suit :

*/5 * * * * /chemin/vers/script1 && /chemin/vers/script2

Je pense que c'est un cas du dernier, où le rapport ne changera pas s'il est généré à partir de données anciennes, ou sera complètement incorrect s'il est généré à partir de données incomplètes, alors pourquoi en créer un autre jusqu'à ce qu'une exécution réussie du premier script ait eu lieu ? Renvoyez plutôt une copie mise en cache du rapport précédent ou rien du tout. Si le premier script a la moindre chance de s'exécuter plus longtemps que l'intervalle cron, il devrait utiliser un verrouillage de base (par exemple avec flock) pour garantir qu'il n'y aura pas d'exécutions concurrentes faisant des demandes en concurrence aux mêmes endroits.