CRON触发的速度有多快?

时间:2018-09-16 12:45:29

标签: cron timezone localtime

第一个示例

假设我有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是否存储了该分钟已执行的数据。

同一问题的另一个变体:

  1. 在11:29:59,NTP服务将时间更正为11:31:00-该作业将在当天全部执行吗?

4 个答案:

答案 0 :(得分:4)

最有信心地回答这个问题的最简单方法是查看cron守护程序的源代码。在线有一些版本,例如this,或者您可以使用apt-get source cron

cron中的滴答周期是要重复睡眠一分钟,如果有工作要做的话,睡眠时间会更少。从睡眠中恢复后,立即检查时间并将结果视为以下UserManager值之一:

  • 预计时间-执行我们期望的所有工作
  • 小前跳(最多5分钟)-在接下来的几分钟内运行作业
  • 介质向前跳跃(最多3个小时,因此包括从春季开始的DST)-首先运行任何通配符作业(因为追赶可能需要一分钟以上的时间),然后才赶上介于中间的固定时间作业< / li>
  • 大跳(两种方式都需要3个小时或更长时间)-从当前时间重新开始
  • 向后跳动(最多3个小时,因此包括DST的结束)-因为任何固定时间的作业都已经“可能”已经运行,所以只运行任何通配符作业,直到时间重新计时为止

如有疑问,消息来源将对这些wakeupKind values进行清晰评论。


修改

要跟踪SignInManager是否可能受到时钟更改的影响,答案似乎在几个Linux手册页中间接存在。

  • 首先,sleep() function的注释确认是由wakeupKind实现的
  • nanosleep()的注释说Linux使用sleep()时钟来测量时间(即使POSIX.1认为不应该)
  • clock_settime()的文档中向下滚动以查看nanosleep()的说明,该说明说明它不受系统时间跳跃的影响,但会受到NTP增量式时钟的影响同步调整。

因此,总而言之,系统管理员风格的时钟更改不会对CLOCK_MONOTONIC产生任何影响。但是例如,如果进行NTP调整并说“稍微”提前时钟,则cron将经历一系列稍微短的CLOCK_MONOTONIC函数调用。

答案 1 :(得分:1)

cron系统有很多实现(请参见here)。最常用的cron之一是Vixie cron。其手册页指出:

  

夏时制和其他时间更改

     

少于三小时的本地时间更改(例如由夏令时更改引起的更改)将以特殊方式处理。这仅适用于在特定时间运行的作业以及按粒度运行的作业          大于一小时。正常安排运行频率更高的作业。

     

如果将时间向前调整一小时,则将在跳过的间隔内运行的那些作业将立即运行。相反,如果将时间向后调整,则可以避免两次执行相同的作业。

     

超过3小时的时间变化被认为是对时钟或时区的更正,并且新时间将立即使用。

     

来源:man 8 cron

我相信这可以回答您的大部分问题。

除了第五点:

  
      
  1. 在11:29:59,NTP服务将时间更正为11:31:00-该作业将在当天全部执行吗?
  2.   

首先,如果NTP将时间校正超过一分钟,则您的时钟非常糟糕!这不应经常发生。通常,启用NTP时可能会有这样的步骤,但是应该少得多。

在任何情况下,如果DeltaT值不高(通常低于125 ms),您的系统就会 slew 时间。 摆幅时间是指更改软件时钟的虚拟频率,以使时钟变快或变慢,直到实现请求的校正为止。延长时钟时间也可能需要一些时间。例如,标准Linux以每秒0.5ms的速率调整时间。

这暗示着(在Vixie cron的假设下,可能还有许多其他假设):

  • 如果NTP跳转超过3小时,则该作业将被跳过
  • 如果NTP的跳跃时间少于3小时但超过125毫秒,则Vixie cron会通过假设跳时的概念很好地处理这项工作。
  • 如果NTP将时间更正的时间少于125毫秒,则cron不会因为回转而注意到时间跳动。

有趣的信息:

答案 2 :(得分:0)

您实际上是在问两个相关的问题。一般的答案取决于它[1],但是我将根据当前正在安装的Debian Linux进行回答:

cron如何处理DST更改和其他与时间相关的“特殊”事件?

在我的Debian Linux系统上,cron处理“ DST和其他与时间相关的更改/修复”(按手册页),以使作业不要运行两次或由于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,则实现的手册页/文档应提供有关运行频率的详细信息,选择修改的crontab,DST处理等的详细信息。如果您确实需要了解特定的详细信息, df778899是正确的,因为您应该根据需要查看实现的源代码...因为有时软件/文档存在错误。

答案 3 :(得分:-2)

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