Exécuter plusieurs tâches cron où une tâche prend beaucoup de temps

J'ai la question générale suivante concernant les tâches cron.

Supposons que j'ai les éléments suivants dans mon crontab:

* 10 * * * * someScript.sh
* 11 * * * * someScript2.sh
30 11 */2 * * someScript3.sh  <-- Takes a long time let's say 36 hours.
* 12 * * * someScript4.sh

Est-il suffisamment intelligent pour exécuter les tâches restantes aux moments appropriés? Par exemple, le long script n'a pas besoin de se terminer?

De plus, que se passe-t-il si le long script initial est toujours en cours d'exécution et qu'il est à nouveau appelé par cron?

Je vous remercie!

Chaque tâche cron est exécutée indépendamment de toute autre tâche que vous avez spécifiée. Cela signifie que votre script de longue durée n'empêchera pas l'exécution d'autres tâches à l'heure spécifiée.

Si l'un de vos scripts est toujours en cours d' exécution à leur prochain intervalle de cron planifié, une autre instance simultanée de votre script sera exécutée.

Cela peut avoir des conséquences imprévues en fonction de ce que fait votre script. Je recommanderais de lire l'article Wikipedia sur le verrouillage de fichiers , en particulier la section sur les fichiers de verrouillage . Un fichier de verrouillage est un mécanisme simple pour signaler qu'une ressource - dans votre cas, le someScript3.shscript - est actuellement «verrouillée» (c'est-à-dire en cours d'utilisation) et ne doit pas être exécutée à nouveau tant que le fichier de verrouillage n'est pas supprimé.

Jetez un œil aux réponses à la question suivante pour plus de détails sur la façon d'implémenter un fichier de verrouillage dans votre script:

• Comment s'assurer qu'une seule instance d'un script bash s'exécute?

Je ne sais pas ce que vous entendez par heure appropriée. Cron démarrera les travaux à l'heure prévue. Il ne vérifie pas les autres travaux planifiés ni les autres instances d'un travail.

Ainsi, les travaux valides que vous définissez seront démarrés à l'heure définie. Tout travail qui s'exécute plus longtemps que l'intervalle défini sera démarré plusieurs fois. Il est de la responsabilité de la personne qui a écrit le travail de l'empêcher de s'exécuter plusieurs fois si cela est nécessaire. Par exemple en vérifiant un fichier de verrouillage ou un fichier PID ou quelque chose.

Il existe des limites évidentes à la quantité de processus pouvant s'exécuter en parallèle, mais ceux-ci ne sont pas spécifiques à cron.

En plus d'autres réponses, en particulier le lien publié par @soulcake: Si vous planifiez une commande longue avec un intervalle trop court, cron exécutera avec plaisir la seconde avant la fin de la première (à moins qu'il n'y ait une sorte de mutex implémenté dans la commande) .

Cela ralentit souvent encore plus la commande d'origine, entraînant l'exécution d'une autre instance avant la fin des précédentes, etc. Ou cela peut être indésirable pour d'autres raisons.

La manière générale d'empêcher est de conditionner l'exécution de la commande avec un garde qui garantit qu'une commande précédente n'est pas en cours d'exécution. Par exemple:

10 * * * * pgrep my_slow_command >/dev/null || /usr/local/bin/my_slow_command

Assurez-vous que pgrep correspond au nom de la commande lors de son exécution, par exemple, les scripts python ont python comme nom de l'exécutable, ce qui n'est probablement pas assez spécifique et vous devrez également faire correspondre le nom du script python.

10 * * * * pgrep -f my_script.py || /usr/local/bin/my_script.py

(pgrep sans l'option '-f' correspond cependant aux noms des scripts bash)

Si vous ne pouvez pas utiliser pgrep pour une raison quelconque:

10 * * * * ps ax | grep [m]y_command || /usr/local/bin/my_command

Les crochets sont utilisés pour éviter de faire correspondre la commande grep elle-même.

J'utilise flock.

* * * * * exec flock --nonblock .ws_client.lock -c ws_client.py >& /tmp/ws_client.out