Bro*_*ana 363 linux debian server-crashes ntp leapsecond
*注意：如果您的服务器由于内核混乱而仍然存在问题，并且您无法重新启动 - 建议在您的系统上安装 gnu date 的最简单解决方案是：date -s now。这将重置内核的内部“time_was_set”变量并修复 Java 和其他用户空间工具中的 CPU 占用 futex 循环。我已经在我自己的系统上跟踪了这个命令，并确认它正在做它在锡上所说的 *
尸检
Anticlimax：唯一死掉的是我的 VPN (openvpn) 链接到集群，所以在它重新建立时有令人兴奋的几秒钟。其他一切都很好，并且在闰秒过去后启动 ntp 就顺利进行了。
我在http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/写下了我当天的全部经历
如果您在http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second查看 Marco 的博客- 他有一个解决方案使用 ntpd -x 在 24 小时内调整时间变化以避免 1 秒跳过。这是运行您自己的 ntp 基础架构的另一种涂抹方法。
就在今天，2012 年 6 月 30 日星期六 - 在格林威治标准时间开始后不久开始。我们在由不同团队管理的不同数据中心的少数服务器都变黑了 - 不响应 ping，屏幕空白。
他们都在运行 Debian Squeeze - 从库存内核到自定义 3.2.21 构建的所有内容。大多数是戴尔 M610 刀片，但我也刚刚丢失了戴尔 R510，其他部门也丢失了其他供应商的机器。还有一个旧的 IBM x3550 崩溃了，我认为它可能无关紧要，但现在我想知道。
我确实从中获得了屏幕转储的一次崩溃说：
[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001] lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0
不幸的是，刀片都应该配置了 kdump，但是它们死得太厉害以至于 kdump 没有触发——而且它们打开了控制台消隐。我现在禁用了控制台消隐，所以手指交叉我会在下一次崩溃后获得更多信息。
只是想知道这是一个共同的话题还是“只是我们”。很奇怪的是，它们是在不同时间购买并由不同管理员运行的不同数据中心的不同单元（我运行的是 FastMail.FM 的）……现在甚至是不同的供应商硬件。大多数崩溃的机器已经运行了数周/数月，并且运行着 3.1 或 3.2 系列内核。
最近的崩溃是一台机器在 3.2.21 上只运行了大约 6 个小时。
解决方法
好的，这就是我解决它的方法。
/etc/init.d/ntp stopfixtime.pl不加争论地跑去看看有闰秒设置fixtime.pl与一个参数，以除去闰秒注意：取决于adjtimex. 我adjtimex在http://linux.brong.fastmail.fm/2012-06-30/adjtimex 上放了一个挤压二进制文件的副本——它可以在不依赖挤压 64 位系统的情况下运行。如果将它放在与 相同的目录中fixtime.pl，则在系统不存在的情况下将使用它。显然，如果您没有挤压 64 位……请找到您自己的。
我ntp明天要重新开始。
正如一位匿名用户所建议的那样 - 跑步的另一种选择adjtimex是自己设置时间，这可能也会清除闰秒计数器。
Dan*_*ing 318
这是由 ntpd 调用 adjtimex(2) 告诉内核插入闰秒时的活锁引起的。参见 lkml 发布http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html
Red Hat 也应该更新他们的知识库文章。https://access.redhat.com/knowledge/articles/15145
更新：Red Hat 有第二篇知识库文章专门针对此问题：https : //access.redhat.com/knowledge/solutions/154713 - 上一篇文章针对的是较早的、不相关的问题
解决方法是关闭ntpd。如果 ntpd 已经发出 adjtimex(2) 调用，您可能需要禁用 ntpd 并重新启动以确保 100% 安全。
这会影响 RHEL 6 和其他运行较新内核（比大约 2.6.26 新）的发行版，但不会影响 RHEL 5。
在实际安排闰秒之前发生这种情况的原因是ntpd 让内核在午夜处理闰秒，但需要提醒内核在午夜之前插入闰秒。因此，ntpd 在闰秒当天的某个时间调用 adjtimex(2)，此时会触发此错误。
如果您安装了 adjtimex(8)，您可以使用此脚本来确定是否设置了标志 16。标志 16 是“插入闰秒”：
adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'
更新：
Red Hat 更新了他们的知识库文章以指出：“RHEL 6 客户可能受到一个已知问题的影响，该问题导致 NMI Watchdog 在收到 NTP 闰秒通知时检测到挂起。正在及时解决此问题。如果您的系统收到闰秒公告并没有遇到这个问题，那么他们就不再受到影响。”
更新：上述语言已从 Red Hat 文章中删除；并添加了第二个 KB 解决方案，详细说明了 adjtimex(2) 崩溃问题：https : //access.redhat.com/knowledge/solutions/154713
但是，IBM 工程师 John Stultz 的 LKML 帖子中的代码更改指出，实际应用闰秒时也可能会出现死锁，因此您可能希望在禁用 ntpd 后通过重新启动或使用 adjtimex(8) 来禁用闰秒。
最终更新：
好吧，我不是内核开发人员，但我在这里再次查看了 John Stultz 的补丁：https ://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a = commit;h =6b43ae8a619d17c4935c3320d2ef9e92bdeed05d
如果我这次没看错，我就错了，在应用闰秒时会出现另一个死锁。根据他们的知识库条目，这似乎也是 Red Hat 的意见。但是，如果您已禁用 ntpd，请将其再禁用 10 分钟，以免在 ntpd 调用 adjtimex(2) 时遇到死锁。
我们很快就会发现是否还有更多错误:)
飞跃后的第二次更新：
我花了最后几个小时通读了 ntpd 和预补丁（有问题的）内核代码，虽然我在这里可能非常错误，但我将尝试解释我的想法：
首先，ntpd 一直调用 adjtimex(2)。它作为其“时钟环路滤波器”的一部分执行此操作，在 ntp_loopfilter.c 中的 local_clock 中定义。您可以在此处查看该代码：http : //www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c（来自 ntp 版本 4.2.6）。
时钟循环过滤器经常运行——它在每次 ntpd 轮询其上游服务器时运行，默认情况下是每 17 分钟或更长时间。时钟环路滤波器的相关位是：
if (sys_leap == LEAP_ADDSECOND)
ntv.status |= STA_INS;
进而：
ntp_adjtime(&ntv)
换句话说，在出现闰秒的日子里，ntpd 设置“STA_INS”标志并调用 adjtimex(2)（通过其可移植性包装器）。
该系统调用进入内核。这是相关的内核代码：https : //github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c
内核代码路径大致是这样的：
这里有一些有趣的事情。
首先，每次调用 adjtimex(2) 时，第 691 行都会取消现有计时器。然后，554 重新创建该计时器。这意味着每次 ntpd 运行其时钟循环过滤器时，都会调用有问题的代码。
因此，我认为 Red Hat 说一旦 ntpd 设置了闰秒标志，系统就不会崩溃，这是错误的。我相信每个运行 ntpd 的系统都有可能在闰秒之前的 24 小时内每 17 分钟（或更多）发生一次活锁。我相信这也可以解释为什么这么多系统崩溃了；与每小时 3 次撞车相比，一次撞车的可能性要小得多。
更新：在https://access.redhat.com/knowledge/solutions/154713 的Red Hat KB 解决方案中，Red Hat 工程师确实得出了相同的结论（运行 ntpd 会不断地遇到错误代码）。事实上，他们比我早几个小时这样做了。这个解决方案没有链接到https://access.redhat.com/knowledge/articles/15145的主要文章，所以我直到现在才注意到它。
其次，这解释了为什么加载的系统更容易崩溃。加载的系统将处理更多的中断，从而导致更频繁地调用“do_tick”内核函数，从而在创建计时器时让此代码有更多机会运行并获取 ntp_lock。
第三，当闰秒真的发生时，系统有没有可能崩溃？我不确定，但可能是的，因为触发并实际执行闰秒调整的计时器（ntp_leap_second，第 388 行）也会获取 ntp_lock 自旋锁，并调用 hrtimer_add_expires_ns。我不知道该调用是否也可能导致活锁，但这似乎并非不可能。
最后，是什么导致闰秒标志在闰秒运行后被禁用？答案是 ntpd 在午夜之后的某个时间点停止设置闰秒标志，当它调用 adjtimex(2) 时。由于未设置标志，第 554 行的检查将不会为真，也不会创建计时器，第 598 行会将 time_state 全局变量重置为 TIME_OK。这解释了为什么如果您在闰秒之后使用 adjtimex(8) 检查标志，您仍然会看到闰秒标志集。
总之，今天最好的建议似乎是我给出的第一个建议：禁用 ntpd，并禁用闰秒标志。
还有一些最后的想法：
06/02 来自约翰·斯图尔茨的更新：
https://lkml.org/lkml/2012/7/1/203
这篇博文详细介绍了为什么闰秒会导致 futex 计时器过早且持续地过期，从而导致 CPU 负载激增。
小智 33
这对我们打击很大。重新启动我们的许多主机后，结果证明以下操作非常简单且完全有效，无需重新启动主机：
/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start
所需要做的就是重置系统时钟。嘘。我六小时前就知道了这一点。
jon*_*jon 24
一个简单的 C 程序，用于清除内核时间状态字段中的闰秒位：
#include <sys/timex.h>
#include <string.h>
#include <stdio.h>
int main(int argc, char **argv) {
struct timex txc;
int ret;
(void) argc;
(void) argv;
bzero(&txc, sizeof(txc));
txc.modes = 0; /* fetch */
ret = adjtimex(&txc);
if (ret < 0) {
perror("adjtimex (get)");
return 1;
}
txc.modes = ADJ_STATUS;
txc.status &= ~16;
ret = adjtimex(&txc);
if (ret < 0) {
perror("adjtimex (set)");
return 1;
}
return 0;
}
另存为lsec.c，编译gcc -Wall -Wextra -o lsec lsec.c并以 root 身份运行。
您可能希望在运行 ntpd 之前停止它，并在闰秒后重新启动 ntpd。
Gre*_*gor 18
事后分析似乎 ./lsec 没有效果。
我们看到的是大量的 softirqd 进程占用 CPU（通常与 java 进程的负载呈线性关系）
使用 ntp 已经应用的闰秒修复 POSTMORTEM 的工作如下：
似乎只需发出：
export LANG="en_EN"; date -s "`date`"
这应该可以减少负载，而无需重新启动 ntpd 或重新启动。或者，您可以发出：
apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start
Luc*_*zzi 16
http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back似乎表明 Debian 挤压内核不会处理闰秒。
comp.protocols.tim.ntp 上的这个线程也很有趣：https ://groups.google.com/forum/?fromgroups#! topic/ comp.protocols.time.ntp/KSflIgjUdPE
也就是说，闰秒还没有发生：23:59:60 UTC
最后，https://access.redhat.com/knowledge/articles/15145有如下说：“闰秒发生时，内核打印一条消息到系统日志。有可能打印这条消息可能导致内核在 Red Hat Enterprise Linux 中崩溃。”