web-dev-qa-db-fra.com

Quelle est la rapidité de déclenchement de CRON?

Premier exemple

Supposons que j'ai un travail CRON

 30 2 * * * ....

Ensuite, cela fonctionnerait à chaque fois quand il est 2h30 du soir (heure locale).

Supposons maintenant que j'ai le fuseau horaire Europe/Germany et que nous sommes le 2017-10-29 (le jour où l’heure DST est activée). Ensuite, ce travail CRON serait exécuté deux fois, non?

Deuxième exemple

Supposons que j'ai le fuseau horaire Europe/Germany et le travail CRON

 30 11 * * * ....

Comme l'Allemagne n'a jamais eu de changement d'heure d'été à 11h30, cela n'interférera pas. Mais l'utilisateur peut changer l'heure locale. Pour être super clair: Cette question ne concerne PAS l’heure d’été .

Pour les cas de test suivants, j'aimerais savoir si/à quelle fréquence le travail CRON est planifié:

  1. À 11: 29: 58.0, l'utilisateur définit l'heure à 11:31:00.
  2. À 11: 29: 59.1, l'utilisateur définit l'heure à 11:31:00.
  3. À 11: 29: 59.6, l'utilisateur définit l'heure à 11:31:00.
  4. À 11: 30: 01.0, l'utilisateur règle l'heure à 11: 29: 59.7 - CRON est-il exécuté directement après?

Ils se résument à Quelle est la rapidité de déclenchement de CRON? , où le 4ème a également la question de savoir si CRON enregistre qu'il a déjà été exécuté pour cette minute.

Une autre variante de la même question:

  1. À 11:29:59, le service NTP corrige l'heure jusqu'à 11:31:00 - le travail sera-t-il exécuté ce jour-là?
crontimezonelocaltime
7
Martin Thoma

Le moyen le plus simple de répondre à cette question en toute confiance est de consulter le code source du démon cron. Il existe quelques versions en ligne comme this , ou vous pouvez utiliser apt-get source cron .

Le cycle de ticks dans cron consiste à dormir à plusieurs reprises pendant une minute, ou moins si un travail est à venir. Immédiatement après être sorti du sommeil, il vérifie l'heure et traite le résultat comme l'une de ces valeurs wakeupKind:

  • Temps prévu - exécuter tous les travaux attendus
  • Petit saut en avant (jusqu'à 5 minutes) - exécute les travaux pour les minutes qui suivent
  • Saut moyen en avant (jusqu'à 3 heures, donc cela inclurait l'heure d'été à partir du printemps) - lancez d'abord les tâches génériques (car le rattrapage peut prendre plus d'une minute), puis rattrapez les tâches intermédiaires à temps fixe
  • Grand saut (3 heures ou plus dans les deux sens) - recommencez avec l'heure actuelle
  • Revenez en arrière (jusqu'à 3 heures, donc la fin de l'heure d'été) - car toutes les tâches à heure fixe ont déjà probablement été exécutées, exécutez uniquement les tâches génériques jusqu'à ce que le temps soit rattrapé.

En cas de doute, la source commente ces valeurs wakeupKind clairement.

Modifier

Pour savoir si sleep() pourrait être affecté par un changement d’horloge, il semble que la réponse se trouve indirectement dans quelques pages de manuel Linux.

  • Premièrement, les notes pour la fonction sleep () confirment que cette fonction est implémentée par nanosleep()
  • Les notes pour nanosleep () say Linux mesure le temps en utilisant l’horloge CLOCK_MONOTONIC (même si POSIX.1 dit que ce n’est pas le cas)
  • Faites défiler un peu dans la documentation pour clock_settime () pour voir l'explication de CLOCK_MONOTONIC, ce qui explique qu'il n'est pas affecté par les sauts de l'heure du système, mais qu'il serait affecté par la synchronisation d'horloge incrémentielle NTP ajustements.

Donc, en résumé, un changement d'horloge de style administrateur système n'aura aucun effet sur la fonction sleep(). Mais par exemple, si un ajustement NTP arrive et dit de faire avancer l'horloge avec précaution, cron subira une série d'appels de fonction sleep() légèrement courts.

4
df778899

Il existe de nombreuses implémentations de systèmes cron (voir ici ). Un des cron les plus couramment utilisés est Vixie cron. Et sa page de manuel déclare:

Heure d'été et autres changements d'heure

Les changements d’heure locale de moins de trois heures, tels que ceux causés par les changements d’heure, sont traités de manière spéciale. Cela s'applique uniquement aux travaux qui s'exécutent à une heure spécifique et aux travaux qui ont une granularité plus d'une heure. Les travaux qui s'exécutent plus fréquemment sont planifiés normalement.

Si le temps a été ajusté d'une heure, les travaux qui auraient été exécutés dans l'intervalle ignoré seront exécutés immédiatement. Inversement, si le temps a été ajusté à l'envers, l'exécution du même travail deux fois est évitée.

Les changements d'heure de plus de 3 heures sont considérés comme des corrections de l'horloge ou du fuseau horaire, et la nouvelle heure est utilisée immédiatement.

source: man 8 cron

Je crois que cela répond à la plupart de vos points.

En plus du point cinq:

  1. À 11:29:59, le service NTP corrige l'heure jusqu'à 11:31:00 - le travail sera-t-il exécuté ce jour-là?

Premièrement, si NTP corrige l'heure avec plus d'une minute, vous avez une très mauvaise horloge! Cela ne devrait pas arriver trop souvent. Généralement, vous pouvez avoir une telle étape lorsque vous activez NTP mais cela devrait être beaucoup moins long.

Dans tous les cas, si le DeltaT n’est pas trop élevé, généralement inférieur à 125 ms, votre système va déplacer le temps. Slewing l'heure signifie modifier la fréquence virtuelle de l'horloge logicielle pour accélérer ou ralentir l'horloge jusqu'à l'obtention de la correction demandée. Ajuster l'horloge plus longtemps peut également prendre du temps. Par exemple, Linux standard ajuste le temps avec un débit de 0,5 ms par seconde.

Cela implique (sous l’hypothèse de Vixie Cron et probablement beaucoup d’autres):

  • Si NTP saute plus de 3 heures, le travail est ignoré
  • Si NTP saute moins de 3 heures mais plus de 125 ms, Vixie Cron gère bien le travail en assumant les concepts de sauts dans le temps.
  • Si NTP corrige le temps pendant moins de 125 ms, cron ne remarque pas le saut temporel dû au pivotement.

Une information intéressante:

1
kvantour

Vous posez en fait deux questions connexes. La réponse générale est que cela dépend [1], mais je vais répondre en fonction de l'installation Debian Linux sur laquelle je suis actuellement:

Comment Cron gère-t-il les modifications de l'heure d'été et d'autres événements spéciaux 'liés au temps?

Sur mon système Linux Debian, cron gère "l'heure d'été et d'autres modifications/corrections liées au temps" (conformément à la page de manuel), de sorte que les tâches non soient exécutées deux fois ou ignorées en raison de modifications telles que DST. (Voir https://debian-handbook.info/browse/stable/sect.task-scheduling-cron-atd.html pour plus de détails.) En lien avec le cinquième point soulevé dans votre deuxième question, je m'attendrais à ce mêmes installations pour traiter les sauts de temps liés au NTP mais ne le savent pas avec certitude.

A quelle fréquence cron est-il déclenché et à quelle vitesse détecte-t-il les modifications de ma crontab?

De nouveau, sur mon système Linux Debian, le démon cron se réveille une fois par minute et détectera et utilisera toutes les modifications apportées à la crontab depuis la dernière vérification/exécution effectuée il y a une minute. Notez qu'il n'y a aucune garantie que cron se déclenche à 12:00:00 ou 12:00:59 ou à une heure spécifique entre (si ce n'est qu'il se déclenche à 12:00: ??), donc si vous changez une crontab à 12 h 17 mais cron mis à feu à 12 h 13, vos modifications ne seront pas prises en compte avant la prochaine exécution (probablement à 12:01:13, bien qu'il puisse y avoir un léger écart dû au Ordonnanceur Linux)

_ {[1] Cela dépend ...

La réponse précise dépend absolument de la plate-forme (Linux/Unix/BSD/OS X/Windows) et de l’implémentation particulière de cron (il ya eu plusieurs versions au cours des décennies, les dérivés de Vixie cron étant répandus sous Linux et BSD par https : //en.wikipedia.org/wiki/Vixie_cron ). Si vous utilisez une application autre que Linux, la page de manuel/la documentation de votre implémentation doit fournir des détails sur la fréquence d’exécution, la collecte des crontabs modifiés, la gestion de la DST, etc. Si vous avez réellement besoin de connaître les détails, df778899 a raison de regarder le code source de votre implémentation en fonction des besoins ... car le logiciel/la documentation est parfois bogué.

0
blihp