Quelle est la vitesse de déclenchement de CRON ?

Question

Premier exemple

Supposons que j'aie un travail CRON

 30 2 * * * ....

Cette opération s'exécuterait alors à chaque fois qu'il est 2h30 du soir (heure locale).

Supposons maintenant que je dispose du fuseau horaire Europe/Germany et que nous sommes le 2017-10-29 (jour du changement d'heure d'été). Alors ce job CRON s'exécutera deux fois, n'est-ce pas ?

Deuxième exemple

Supposons que je dispose du fuseau horaire Europe/Germany et le travail CRON

 30 11 * * * ....

Comme l'Allemagne n'a jamais eu de changement d'heure d'été à 11h30, il n'y aura pas d'interférence. Mais l'utilisateur peut changer l'heure locale. Pour être très clair : Cette question ne porte pas sur l'heure d'été. .

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

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

Elles se résument à Quelle est la vitesse de déclenchement de CRON ? Dans le quatrième cas, la question se pose également de savoir si CRON enregistre le fait qu'il a déjà été exécuté pendant la minute en question.

Une autre variante de la même question :

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

Answer 1

Le moyen le plus simple de répondre à cette question avec confiance est de jeter un coup d'œil aux sources du démon cron. Il existe plusieurs versions en ligne, comme este ou vous pouvez utiliser apt-get source cron .

Le cycle de tic-tac de cron consiste à dormir de manière répétée pendant une minute, ou moins s'il y a un travail en cours. Immédiatement après avoir émergé du sommeil, il vérifie l'heure et traite le résultat comme l'un des suivants wakeupKind valeurs :

• Temps prévu - exécuter tous les travaux prévus
• Petits sauts en avant (jusqu'à 5 minutes) - exécuter les tâches pour les minutes intermédiaires
• Saut moyen vers l'avant (jusqu'à 3 heures, ce qui inclut l'heure d'été qui commence au printemps) - exécuter d'abord les travaux de remplacement (parce que le rattrapage peut prendre plus d'une minute), puis rattraper les travaux à heure fixe intermédiaires.
• Saut important (3 heures ou plus dans un sens ou dans l'autre) - recommencer à l'heure actuelle
• Saut en arrière (jusqu'à 3 heures, donc y compris la fin de l'heure d'été) - étant donné que tous les travaux à heure fixe ont "probablement" déjà été exécutés, n'exécutez les travaux de remplacement que jusqu'à ce que l'heure soit rattrapée.

En cas de doute, les commentaires de la source sont les suivants valeurs wakeupKind clairement.

---

Editar

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

• Tout d'abord, les notes pour le fonction sleep() qui est mis en œuvre par nanosleep()
• Les notes pour nanosleep() disons que Linux mesure le temps à l'aide de la fonction CLOCK_MONOTONIC l'horloge (même si POSIX.1 dit qu'elle ne doit pas l'être)
• Descendez un peu dans la documentation pour trouver clock_settime() pour voir l'explication de CLOCK_MONOTONIC qui explique qu'il n'est pas affecté par les sauts de l'heure du système, mais qu'il serait affecté par les ajustements incrémentaux de la synchronisation de l'horloge de type NTP.

En résumé, un changement d'horloge à la manière de l'administrateur du système n'aura aucun effet sur le système d'information de l'entreprise. sleep() . Mais par exemple, si un ajustement NTP est venu et a dit d'avancer "doucement" l'horloge, cron connaîtra une série d'ajustements légèrement courts. sleep() les appels de fonction.

Answer 2

Il existe de nombreuses implémentations de systèmes cron (voir aquí ). L'un des cron les plus utilisés est Vixie cron. Sa page de manuel indique

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

Les changements d'heure locale de moins de trois heures, tels que ceux causés par le changement d'heure d'été, sont traités d'une manière particulière. Cela ne s'applique qu'aux tâches exécutées à une heure précise et aux tâches exécutées avec une granularité supérieure à une heure. Les travaux qui s'exécutent plus fréquemment sont planifiés normalement.

Si l'heure a été avancée d'une heure, les travaux qui auraient dû être exécutés dans l'intervalle qui a été supprimé seront exécutés immédiatement. Inversement, si l'heure a été ajustée vers l'arrière, on évite d'exécuter deux fois le même travail.

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 : <code>man 8 cron</code>}

Je pense que cela répond à la plupart de vos questions.

En complément du point 5 :

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

Tout d'abord, si NTP corrige l'heure de plus d'une minute, vous avez une très mauvaise horloge ! Cela ne devrait pas se produire trop souvent. En général, il se peut que vous ayez un tel écart lorsque vous activez NTP, mais il devrait alors être beaucoup moins important.

En tout état de cause, si le DeltaT n'est pas trop élevé, généralement inférieur à 125 ms, votre système pourra pivoter l'époque. Manœuvre les moyens temporels de modifier la fréquence virtuelle de l'horloge logicielle pour que l'horloge aille plus vite ou plus lentement jusqu'à ce que la correction demandée soit obtenue. L'asservissement de l'horloge pendant une période plus longue peut également nécessiter un certain temps. Par exemple, Linux standard ajuste l'heure à une vitesse de 0,5 ms par seconde.

Cela implique, (sous l'hypothèse de Vixie cron, et probablement beaucoup d'autres) :

• Si le NTP saute plus de 3 heures, le travail est ignoré.
• Si NTP fait des sauts de moins de 3 heures mais de plus de 125 ms, le cron de Vixie s'en charge gentiment en assumant les concepts des sauts de temps.
• Si NTP corrige l'heure pour moins de 125 ms, cron ne remarque pas le saut de temps dû au pivotement.

---

Informations intéressantes :

• RFC5905 : Network Time Protocol Version 4 : Spécification du protocole et des algorithmes
• La FAQ et le mode d'emploi de NTP
• https://wiki.gentoo.org/wiki/Cron/en

Answer 3

Vous posez en fait deux questions liées. La réponse générale est que cela dépend[1], mais je vais répondre en me basant sur l'installation Linux Debian sur laquelle je me trouve en ce moment :

Comment cron gère-t-il les changements d'heure d'été et d'autres événements "spéciaux" liés au temps ?

Sur mon système Linux Debian, cron gère "DST and other time-related changes/fixes" (selon la page de manuel) de manière à ce que les tâches ne sont exécutées deux fois ou sautées en raison de changements tels que l'heure d'été. (Voir https://debian-handbook.info/browse/stable/sect.task-scheduling-cron-atd.html Pour ce qui est du cinquième point soulevé dans votre deuxième question, je m'attendrais à ce que ces mêmes installations traitent les sauts de temps liés à NTP, mais je n'en suis pas certain.

Quelle est la fréquence de déclenchement de cron et la rapidité avec laquelle il prend en compte les modifications de ma crontab ?

Encore une fois, sur mon système Linux Debian, le démon cron se réveille une fois par minute et détecte et utilise tout changement apporté à la crontab depuis la dernière vérification/exécution, 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 à un moment précis entre les deux (seulement qu'il se déclenche quand l'heure est 12:00: ??) donc dans le cas où vous changez une crontab à 12:00:17 mais que cron s'est déclenché à 12:00:13, vos changements ne seront pas pris en compte jusqu'à la prochaine exécution (très probablement à 12:01:13 bien qu'il puisse y avoir une légère variance due à l'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 y en a eu plusieurs au cours des décennies, les dérivés de Vixie cron étant prédominants sous Linux et BSD par exemple). https://en.wikipedia.org/wiki/Vixie_cron ). Si vous utilisez autre chose que Linux, la page de manuel ou la documentation de votre implémentation devrait fournir des détails sur la fréquence d'exécution, les crontabs modifiées, la gestion de l'heure d'été, etc. Si vous avez vraiment besoin de connaître les détails spécifiques, df778899 a raison de dire que vous devriez regarder le code source de votre implémentation si nécessaire... parce que parfois les logiciels/documentations sont bogués.

Answer 4

Sur mac OS :

$> man cron
...
Available options:

 -s      Enable special handling of situations when the GMT offset of the local timezone changes, such as the switches between the standard time and daylight saving time.

         The jobs run during the GMT offset changes time as intuitively expected.  If a job falls into a time interval that disappears (for example, during the switch from standard time) to daylight saving time
         or is duplicated (for example, during the reverse switch), then it is handled in one of two ways:

         The first case is for the jobs that run every at hour of a time interval overlapping with the disappearing or duplicated interval.  In other words, if the job had run within one hour before the GMT
         offset change (and cron was not restarted nor the crontab(5) changed after that) or would run after the change at the next hour.  They work as always, skip the skipped time or run in the added time as
         usual.

         The second case is for the jobs that run less frequently.  They are executed exactly once, they are not skipped nor executed twice (unless cron is restarted or the user's crontab(5) is changed during
         such a time interval).  If an interval disappears due to the GMT offset change, such jobs are executed at the same absolute point of time as they would be in the old time zone.  For example, if exactly
         one hour disappears, this point would be during the next hour at the first minute that is specified for them in crontab(5).

 -o      Disable the special handling of situations when the GMT offset of the local timezone changes, to be compatible with the old (default) behavior.  If both options -o and -s are specified, the option
         specified last wins.