闰秒对 Unix 系统有什么危害？

Question

RedHat 在其主页上发出警告：

闰秒事件将在 2016 年 12 月 31 日 23h 59m 60s UTC 发生。

它的前缀是一个感叹号，看起来很重要。闰秒对系统有什么危害？我们如何处理？

Answer 1

没有任何。

闰秒自 1972 年以来一直在发生，而 Unix 系统在这段时间里一直安然无恙地度过难关。

这一次，RedHat 选择在其客户支持 WWW 站点的顶部发布一条琥珀色警报消息，这给人们留下了非常错误的印象，并导致人们认为它类似于零日病毒警报，并以某种方式做出反应例如可以在Leap second Bug 2016 年 12 月 31 日看到的“闰秒错误”。

闰秒不是错误，Unix 系统可以很好地处理它们。几十年来，C 库一直提倡这样一种想法，即结构的tm_sec字段有时tm可以具有 60 值。

事实上，唯一真正的问题是 Unix 和 Linux 系统根据口味有多种不同的应对方式。因此，人们必须知道自己选择了什么设置，才能知道需要采取哪些行动（如果有的话）。

RedHat 页面将其隐藏在广泛的背景下，对 TAI-10 系统做出虚假假设，并且不是一般询问有关 Unices 和 Linux 操作系统的问题的答案（尽管这是一个很好的答案）仅限于 RedHat Linux 的世界观）。

从根本上说，您需要回答三个问题才能知道您需要做什么：

• 您的内核时钟是否以 UTC 运行？还是在 TAI-10 中？
• 您使用什么将机器的时钟与其他系统同步？
• 其他系统如何处理闰秒？

一些应该怎么做的案例

您的内核时钟是 TAI-10 并且机器正在使用 TAI-aware 工具与 TAI-10 服务器同步

同步工具将类似于 Daniel J. Bernstein 的taiclock、Laurent Bercot 的s6-taiclock或 OpenBSD 的rdate默认 TAI-10 模式。

在这种情况下，您几乎不需要做任何事情，除非确保您的闰秒表是最新的。内核时钟保持每秒 1 SI 秒的滴答声（允许对振荡器漂移等进行修正），闰秒表处理从 TAI-10 到 UTC 的调整。

有两组表格需要更新：

• 您的right/时区文件中的那些，您可以通过确保您的系统上有最新版本的时区文件包（无论是什么）来保持最新
• Bernstein 和其他人的工具集使用的那些，在 /etc/leapsecs.dat

  M.伯恩斯坦一直没有更新了leapsecs.dat在cr.yp.to，但我已经发布了更新leapsecs.dat，其中包括2016年12月31日23:59:60 UTC闰秒，封装在一个leapsecs包。

由于您同步的服务器也使用 TAI-10，它们发布的秒数也旨在始终保持 1 SI 秒长。使用 TAI-10 的服务器不会踩踏、旋转或拖尾。每个人都在固定长度的 SI 秒上滴答滴答，而闰秒仅作为您的 C 库的工件可见。

您的内核时钟是 TAI-10，并且机器正在使用 TAI 感知工具与 UTC 服务器同步

同步工具将是 OpenBSDrdate在其 UTC 模式下的东西。

同样，在这种情况下，您几乎不需要做任何事情，除非确保您的闰秒表是最新的，就像在前面的情况下一样。内核时钟再次以每秒 1 SI 秒的速度滴答作响。

问题是服务器没有。

• 如果他们涂抹闰秒，那么他们报告的一年中最后一天的大部分时间都略有放缓。您的时间同步工具已经不必要地调整了 TAI-10 以保持与这个错误的 UTC 同步，当闰秒到来时，TAI-10 最终会落后一秒。在闰秒之后，您的同步工具将需要立即加快时钟速度以赶上他们在同步到超过 SI 秒的 UTC 秒和系统时钟秒时错过的额外 TAI-10 滴答声将短于 SI 秒以进行补偿。
• 如果他们扭转了闰秒，那么他们将在新年第一天的短时间内报告略微提前。您的时间同步工具将不必要地调整 TAI-10 以保持与这个错误的 UTC 同步。具有讽刺意味的是，它们会在闰秒立即开始使用 TAI-10 正确，并且在第二天逐渐偏离正确，然后再回来，因为时间服务器逐渐减慢到 UTC 而您的同步工具同时尝试将 TAI-10 加速到其错误的 UTC 时间。
• 如果步骤闰秒，他们根本不会单调递增的时间向您汇报，但闰秒你的同步工具，在闰秒的那一刻做了正确的应该实际计算的东西，除非从UTC的报告服务器不明确。不过，它们至少会以每秒 1 SI 秒的速度滴答作响，并且 TAI-10 将在前后几天保持正确，并且不会因不必要地尝试将 TAI-10 与 UTC 时间同步而摇摆不定其实错了。

因此，如果您使用 TAI-10 运行，您往往会喜欢步进闰秒的UTC 时间服务器，因为其他选项实际上会导致您的 TAI-10 时间不必要地同步到加快或减慢 UTC 时间，并丢失它的时间SI 秒每秒性质。

您的内核时钟是 UTC，并且机器正在使用 UTC 工具与 UTC 服务器同步。

这种情况根据您要同步到的时间服务器执行的操作进行细分。

• 如果他们涂抹闰秒，那么他们报告的一年中最后一天的大部分时间都略有放缓。您的时间同步工具将与之同步，您的时钟将落后一天。
• 如果他们扭转了闰秒，那么他们将在新年第一天的短时间内报告略微提前。您的时间同步工具将与之同步，您的时钟将提前一天的一部分时间。
• 如果步骤闰秒，他们根本不会单调递增的时间向您汇报，并到您的同步工具，它会出现系统时钟突然打捞由第二和需要加以纠正。它们的反应取决于您如何配置同步工具。
  • 他们可能只是步骤的系统时钟过，在这种情况下，你的应用程序将通过第二看时间倒退。
  • 他们更有可能杀死系统时钟，虽然; 在这种情况下，您的机器会在一段时间内滴答比实际 SI 秒长的秒数，并且会提前一天的一部分时间。
• 如果他们宣布闰秒，这只是警告即将到来的一步，那么他们将决定如何做给您的同步工具。
  • 他们可能只是步骤的系统时钟过，在这种情况下，你的应用程序将通过第二看时间倒退。
  • 他们更有可能转换或涂抹系统时钟，虽然; 在这种情况下，您的机器将在前一天或后一天滴答比实际 SI 秒长的秒数。

结果

只有在 UTC-servers+UTC-machine 中的一种情况下，您的机器时间才会正确，即应用程序看到时间倒退的情况，这是 Unix 应用程序不喜欢看到的。在所有其他 UTC-servers+UTC-machine 情况下，您的机器时间最多会出现一天不正确。

在 TAI-10-servers+TAI-10-machine 的情况下，您的机器时间将始终正确。在其中一种 UTC-server+TAI-10-machine 情况下，即服务器步进时间的情况，您的机器时间也将始终正确，除非它恰好在不明确的 UTC 时间上进行轮询。

您的机器时间不正确的后果是在应用程序级别。操作系统对此很好。（与流行的看法相反，POSIX 实际上允许系统时钟出错，这可能是故意的。）例如，如果您执行诸如按秒计费之类的操作，那么您对一秒有多长以及每一秒何时发生的想法, 与您客户的想法不同，可能是两天。您的客户和您可能没有选择相同的设置。

再有就是你的选择要同步同一套混合时间服务器，其中一些的可能的问题杀UTC，其中一些步骤UTC，并且其中一些涂抹UTC。在这种情况下会发生很多欢笑，因为您将同步工具搞混了。也有很多讽刺。“笨”同步工具比“智能”工具更好地处理去同步的时间源，后者试图找出哪个时间源告诉正确的时间。在这种特殊情况下，只有步进器甚至会告诉正确的时间。而slewers和smearers对错误的UTC时间有矛盾的想法。

最后一个不光彩的提及是在 RedHat 页面上讨论的 Linux 内核。同步工具可以选择自己步进时间，也可以指示内核执行此操作。正如 RedHat 报告的那样，这方面存在问题的历史，从内核中的内部计时机制无法正常工作到机器冻结。

进一步阅读

• https://unix.stackexchange.com/a/294715/5132
• https://unix.stackexchange.com/a/327403/5132
• https://askubuntu.com/questions/416417/