Как быстро запускается CRON?

Question

Первый пример

Предположим, у меня есть работа CRON

 30 2 * * * ....

Тогда это будет выполняться каждый раз, когда ночью 2:30 (по местному времени).

Теперь предположим, что у меня есть часовой пояс Europe/Germany, и это 2017-10-29 (день, когда переключается летнее время). Тогда эта работа CRON будет выполняться дважды, верно?

Второй пример

Предположим, у меня есть часовой пояс Europe/Germany и задание CRON

 30 11 * * * ....

Поскольку в Германии в 11:30 не было изменений летнего времени, это не помешает. Но пользователь может изменить местное время. Чтобы быть супер ясным: Этот вопрос НЕ о DST .

Для следующих тестовых случаев я хотел бы знать, если / как часто запланировано задание CRON:

1. В 11: 29: 58.0 пользователь устанавливает время 11: 31: 00
2. В 11: 29: 59.1 пользователь устанавливает время 11: 31: 00
3. В 11: 29: 59.6 пользователь устанавливает время 11: 31: 00
4. В 11: 30: 01.0 пользователь устанавливает время 11: 29: 59.7 - выполняется ли CRON непосредственно после этого?

Они сводятся к Как быстро запускается CRON? , где у 4-го также есть вопрос, сохраняет ли CRON то, что он уже был выполнен на эту минуту.

Другой вариант того же вопроса:

5. В 11:29:59 служба NTP корректирует время до 11:31:00 - будет ли вообще выполнено задание в этот день?

Answer 1

Существует много реализаций систем cron (см. здесь ).Один из наиболее часто используемых cron - это Vixie cron.А на его странице руководства:

Летнее время и другие изменения времени

Изменения местного времени менее трех часов, например, вызванные переходом на летнее времяЭкономия времени меняется, обрабатываются особым образом.Это относится только к заданиям, которые выполняются в определенное время, и к заданиям, которые выполняются с гранулярностью больше одного часа.Задания, которые выполняются чаще, планируются как обычно.

Если время было настроено на один час вперед, те задания, которые должны были бы выполняться в пропущенном интервале, будут запущены немедленно.И наоборот, если время было скорректировано в обратном направлении, то повторное выполнение одного и того же задания исключается.

Изменения времени более чем на 3 часа считаются корректировкой часов или часового пояса, и новое время используется немедленно.

_{источник: man 8 cron}

Я считаю, что это отвечает на большинство ваших вопросов.

В дополнение к баллупять:

В 11:29:59 служба NTP корректирует время до 11:31:00 - будет ли вообще выполнено задание в этот день?

Прежде всего, если NTPисправляет время более чем на минуту, у вас очень плохие часы!Это не должно случаться слишком часто.Как правило, у вас может быть такой шаг, когда вы включаете NTP, но тогда он должен быть намного меньше.

В любом случае, если DeltaT не слишком высокий, обычно ниже 125 мс, ваша система будет убывать время. Slewing время означает изменение виртуальной частоты программных часов, чтобы часы работали быстрее или медленнее, пока не будет достигнута требуемая коррекция.Поворот часов на большее количество времени может также потребовать некоторого времени.Например, стандартный Linux регулирует время со скоростью 0,5 мс в секунду.

Это подразумевает (в предположении Vixie cron и, вероятно, многих других):

• Если NTPскачки более 3 часов, задание пропускается
• Если NTP скачет менее 3 часов, но более 125 мс, Vixie cron прекрасно справляется с заданием, предполагая концепции скачков времени.
• Если NTP корректирует время менее 125 мс, cron не замечает скачок времени из-за поворота.

---

Интересная информация:

• RFC5905: Протокол сетевого времени версии 4: Спецификация протокола и алгоритмов
• Часто задаваемые вопросы и инструкции по NTP
• https://wiki.gentoo.org/wiki/Cron/en

Answer 2

Самый простой способ ответить на этот вопрос с уверенностью - взглянуть на источник для демона cron.Есть несколько версий онлайн, таких как this , или вы можете использовать apt-get source cron .

Цикл тика в cron заключается в повторном сне в течение минуты,или меньше, если есть работа, подходящая.Сразу же после выхода из режима сна он проверяет время и рассматривает результат как одно из следующих значений wakeupKind:

• Ожидаемое время - запустите все ожидаемые нами задания
• Небольшой скачоквперед (до 5 минут) - запускать задания за прошедшие минуты
• Средний скачок вперед (до 3 часов, так что это будет включать DST, начиная с весны) - сначала запускать любые подстановочные задания (потому чтоможет занять больше минуты), а затем наверстать упущенное при выполнении заданий с фиксированным временем
• Большой прыжок (3 часа и более в любом случае) - начать заново с текущим временем
• Перейти назад (вверхдо 3 часов, включая конец летнего времени) - поскольку любые задания с фиксированным временем «вероятно» уже выполнялись, запускайте любые подстановочные задания только до тех пор, пока время не будет восстановлено

В случае сомненийисточник комментирует эти значения wakeupKind явно.

---

Редактировать

Чтобы выяснить, может ли sleep() повлиять на изменение часовэтоks, как ответ косвенно есть в нескольких руководствах Linux.

• Во-первых, примечания для функции sleep () подтверждают, что реализовано с помощью nanosleep()
• В примечаниях к nanosleep () говорится, что Linux измеряет время, используя CLOCK_MONOTONIC часы (даже если POSIX.1 говорит, что это не должно)
• Прокрутите немного вниздокументы для clock_settime () , чтобы увидеть объяснение CLOCK_MONOTONIC, которое объясняет, что на него не влияют скачки системного времени, но это будет зависеть от дополнительных настроек синхронизации часов в стиле NTP.

Итак, в общем, изменение часов в стиле системного администратора не повлияет на sleep().Но, например, если в настройку NTP поступило «мягкое» ускорение тактовой частоты, cron получит серию коротких вызовов функции sleep().

Answer 3

Вы на самом деле задаете два связанных вопроса. Общий ответ - это зависит [1], но я отвечу на основании установки Debian Linux, на которой я сейчас нахожусь:

Как cron обрабатывает изменения летнего времени и другие «особые» события, связанные со временем?

В моей системе Debian Linux cron обрабатывает DST и другие изменения / исправления, связанные со временем (на странице man), так что задания не запускаются дважды или пропускаются из-за таких изменений, как DST. (Подробнее см. https://debian -handbook.info / browse / stable / sect.task-scheduling-cron-atd.html ). В связи с 5-м пунктом, поднятым во втором вопросе, я ожидаю, что те же средства, чтобы справляться с скачками времени, связанными с NTP, но не знаю наверняка.

Как часто запускается cron и как быстро он воспринимает мои изменения crontab?

Опять же, в моей системе Debian Linux демон cron просыпается раз в минуту и ​​обнаруживает и использует любые изменения crontab, сделанные человеком с момента предыдущей проверки / запуска минуту назад. Обратите внимание, что нет никакой гарантии, что cron сработает в 12:00:00 или 12:00:59 или в любое другое конкретное время между (только если он сработает, когда время 12:00: ??), так что в случае, если вы измените crontab в 12:00:17, но cron сработал в 12:00:13, ваши изменения не будут приняты до следующего запуска (скорее всего, в 12:01:13, хотя возможны небольшие отклонения из-за Планировщик Linux)

[1] Зависит от ...

Точный ответ абсолютно зависит как от платформы (Linux / Unix / BSD / OS X / Windows), так и от конкретной реализации cron (в течение нескольких десятилетий производные Vixie cron преобладали в Linux и BSD на https://en.wikipedia.org/wiki/Vixie_cron). Если вы используете что-то отличное от Linux, страница руководства / документация для вашей реализации должна содержать подробную информацию о специфике того, как часто она запускается, подбирает модифицированные crontabs, обработку DST и т. Д. Если вам действительно нужно Чтобы узнать конкретные детали, df778899 прав в том, что вам нужно смотреть на исходный код вашей реализации по мере необходимости ... потому что иногда программное обеспечение / документация содержит ошибки.

Answer 4

В 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.