Quelle est la précision d'un démon cron?

22

Le planificateur de tâches cron est-il vraiment précis?

Je veux dire, j'ai besoin d'un script pour exécuter tous les soirs le plus tard possible, MAIS avant 00h00 du lendemain.

Idéalement, j'exécuterais une tâche cron à 23 h 59 (ou 23 h 59), mais le système sera-t-il vraiment précis? Puisqu'une seconde compte, dois-je régler le cron job à 23:58 pour le laisser un peu de temps?

linux cron

— Sébastien
source

13

Pourquoi avez-vous ces exigences? J'ai le sentiment qu'il y aura une meilleure façon de faire tout ce que vous essayez vraiment de faire, et vous pourriez tout aussi bien poser des questions à ce sujet. (Cela demandera un peu plus d'efforts que la simple planification d'un travail cron, mais peut-être pas beaucoup plus.)

— David Z

J'avais l'habitude d'utiliser un vieux cron stupide avec une précision de 10 minutes.

— joshudson

7

Votre exigence ne me semble pas très fiable. Que faites-vous si votre système a une charge élevée vers minuit. Sauf si vous avez un système RT, vous ne pouvez rien garantir.

— Thomas Erker

Considérez que même si vous parvenez à vous procurer un serveur qui est toujours disponible et peut toujours terminer votre travail en moins d'une seconde, il y a toujours des choses qui peuvent mal tourner. Par exemple, votre horloge peut commencer à dériver sans que vous vous en rendiez compte. C'est vraiment, vraiment fragile et je suis d'accord avec les commentaires ci-dessus que le système doit changer.

— Chris Hayes

24

Ce que cron peut garantir, c'est que votre travail commencera au plus tôt à l'heure spécifiée (sous réserve de la précision de l'horloge système). Mais il n'y a aucun moyen de vous donner une garantie quant à l'heure de fin de l'emploi. Cela dépendra de nombreux facteurs:

Quelle est la charge du système
Que fait le travail
Lenteur due à des problèmes matériels
Lenteur due à des problèmes de réseau (en supposant que le travail dépend du réseau)

Ma recommandation est de changer votre conception de telle sorte qu'un temps d'achèvement spécifique ne soit pas une exigence.

— kasperd
source

1

La façon la plus simple de le faire est probablement de faire en sorte que le travail démarré via cron crée un fichier pour indiquer qu'il est en cours d'exécution qui est supprimé à chaque fois que le travail se termine (avec succès ou non), puis le travail suivant (en supposant que c'est le but) attendez que le fichier disparaisse avant de faire quoi que ce soit.

— un CVn le

@ MichaelKjörling Vous devez utiliser un répertoire, plutôt qu'un fichier, car la recherche d'un fichier et sa création ne sont pas atomiques .

— 8bittree

1

@ 8bittree, vous pouvez également utiliser le troupeau s'il est disponible.

— user9517 prend en charge GoFundMonica

1

@ MichaelKjörling Mais pourquoi s'embêter avec le cas peut-être correct alors que le cas correct est également plus simple?

— 8bittree

4

@ 8bittree Si vous utilisez O_CREATet O_EXCLflags, il sera atomique tant que le fichier se trouve sur un système de fichiers local.

— kasperd

14

Je suppose que cela dépend de votre démon cron, mais la documentation et la norme indiquent que si vous spécifiez des minutes, le travail s'exécutera à la minute spécifiée.

Voir:

Sachez que votre script sera démarré lorsque l'horloge passera à l'heure correcte, mais se terminera quelque temps après.

— Falcon Momot
source

J'ai un serveur virtuel avec une charge très faible, et pourtant un cron qui est configuré pour s'exécuter toutes les minutes démarre parfois à 0 s, 1 s, 2 s, parfois jusqu'à 17 s. Je suppose que cron peut être moins précis sur un serveur virtuel, car d'autres processus en dehors de ce serveur peuvent affecter la disponibilité des ressources telles que le processeur.

— Liam

8

Habituellement, cron démarre à 23:59:00 , analyse tous vos fichiers crontab, filtre ceux qui sont pertinents pour 23:59 puis les démarre. La numérisation de ces fichiers est très rapide, car ils ne sont pas nombreux et ne comportent que quelques lignes. Donc, généralement, les tâches cron commencent à 23:59:00 ou 23:59:01 Il existe des moyens sûrs de ralentir intentionnellement ce processus. (ajoutez des millions de lignes à la crontab, par exemple). Si le système est totalement surchargé, cela ne fonctionnera pas aussi vite.

De plus, cela dépend évidemment de l'implémentation.

Si vous avez besoin d'heures de démarrage très précises, il vaut mieux créer un programme qui dort jusqu'à l'heure souhaitée, puis s'exécute (par exemple en utilisant c ++ 11 ). Mais sur un OS non temps réel, cela ne sera pas exact non plus! De plus, l'horloge du PC ne connaît pas l'heure exacte!

Dans tous les cas, cela garantit uniquement que le programme démarre (plus ou moins) à l'heure souhaitée. Il ne peut y avoir aucune garantie que le programme se termine avec succès jusqu'à un moment donné, donc je crois fermement que vous devriez changer quelque chose sur cette exigence.

— Josef
source

2

Je crois que les crontabs sont conservés en mémoire - si vous modifiez directement les fichiers derrière crontab (au lieu de crontab -e, qui avertit cron une fois terminé), les changements ne prendront pas effet. cron a des tonnes de temps d'arrêt pour déterminer les travaux à venir, il peut "dormir" jusqu'à la seconde exacte à laquelle le travail doit s'exécuter.

— AMADANON Inc.

0

Cela dépend de votre temps d'exécution global du script et de la précision de l'heure du serveur.

59 23 * * * /some/script/file.sh

lancera votre script exactement à 23h59, mais, si vous avez des commandes qui fonctionnent longtemps, une partie du script peut être exécutée après minuit.

— homme étrange
source

exactement à 23h59 , donc ça peut être de 23h59 à 23h59?

— AL

2

Vous n'avez pas de secondes en cron normal. Pour obtenir ces 59 secondes supplémentaires, vous devez ajouter une «attente (59)» en haut de votre code.

— Henry's Cat

4

@AL dans la pratique, je l'ai toujours vu s'exécuter à xx: xx: 00 ou xx: xx: 01, mais sur un système lourdement chargé, il n'y a pas et il ne peut y avoir aucune promesse.

— hobbs