在a日第二天，是否有人遇到Linux服务器崩溃率很​​高的情况？

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

#1 楼

这是由ntpd调用adjtimex（2）告诉内核插入a秒时的活锁引起的。请参阅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的发行版）的发行版。 ），而不是RHEL5。

之所以发生这种情况，是因为ntpd允许内核在午夜处理handle秒，但是需要提醒内核插入午夜之前second秒。因此，ntpd在the秒的某天调用adjtimex（2），这时会触发此错误。

如果安装了adjtimex（8），则可以使用此脚本来确定是否标记设置为16。标志16是“插入ins秒”：

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & ) && print "leap second flag is set:\n"'

更新：

Red Hat更新了其知识库文章，以指出：“ RHEL 6客户可能受到已知问题的影响，该问题导致NMI看门狗在收到NTP leap秒通知时检测到挂起。此问题正在得到及时解决。如果您的系统收到the秒通知并且没有遇到此问题，则说明它们不是受影响时间更长。”

更新：以上语言已从Red Hat文章中删除；并添加了第二个KB解决方案，详细说明了adjtimex（2）崩溃问题：https://access.redhat.com/knowledge/solutions/154713

但是，IBM工程师John Stultz在LKML帖子中的代码更改指出，在实际应用leap秒时也可能会出现死锁，因此您可能希望通过在禁用ntpd后重新引导或使用adjtimex（8）来禁用the秒。

最终更新：

好吧，我不是内核开发人员，但是我在这里再次查看了John Stultz的补丁：https://git.kernel.org/?p= linux / kernel / git / torvalds / linux-2.6.git; a = commit; h = 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

如果我这次读对了，那我就错了，那就是在跨越时出现另一个死锁第二个被应用。基于其KB条目，这似乎也是Red Hat的意见。但是，如果您已禁用ntpd，请再禁用10分钟，以免在ntpd调用adjtimex（2）时遇到死锁。

我们将查找是否有任何问题。很快会有更多错误：）

-LEAP-LEAP第二次更新：在这里可能是非常错误的，我将尝试解释我的想法：

首先，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)

，在a秒的日子里，ntpd设置“ STA_INS”标志并调用adjtimex（2）（通过其可移植性包装程序）。

该系统调用进入了内核。以下是相关的内核代码：https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

内核代码路径大致是这样的：


行663-do_adjtimex例程的开始。
行691-取消任何现有的leap秒计时器。
行709-抓取ntp_lock自旋锁（此锁涉及可能发生的活锁崩溃）
第724行-调用process_adjtimex_modes。
第616行-调用process_adj_status。
590行-根据设置的标志设置time_status全局变量在adjtimex（2）调用
第592行中-检查time_state全局变量。在大多数情况下，请调用ntp_start_leap_timer。
第554行-检查time_status全局变量。将设置STA_INS，因此将time_state设置为TIME_INS并调用hrtimer_start（另一个内核函数）以启动the秒计时器。在创建计时器的过程中，此代码捕获了xtime_lock。如果发生这种情况，而另一个CPU已经抓住了xtime_lock和ntp_lock，则内核活动锁。这就是John Stultz编写补丁以避免使用hrtimers的原因。这就是今天导致每个人麻烦的原因。第598行-如果ntp_start_leap_timer实际上没有启动跳转计时器，请将time_state设置为TIME_OK
第751行-假设内核没有活动锁定，则取消栈堆栈，并且ntp_lock自旋锁被释放。

这里有一些有趣的事情。

首先，每次调用adjtimex（2）时，第691行都会取消现有计时器。然后，554重新创建该计时器。这意味着ntpd每次运行其时钟循环过滤器时，都会调用错误代码。

因此，我相信Red Hat错了，因为他们说一旦ntpd设置了leap秒标志，系统就不会崩溃。我相信每个运行ntpd的系统都有潜力在the秒之前的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。

第三，实际上发生leap秒时，系统是否有崩溃的可能？我不确定，但可能是肯定的，因为触发并实际执行leap秒调整的计时器（第388行的ntp_leap_second）也获取了ntp_lock自旋锁，并调用了hrtimer_add_expires_ns。我不知道该调用是否也可能导致活动锁定，但这似乎并非不可能。

最后，是什么原因导致the秒标志在the秒之后被禁用已经跑了吗？答案是有ntpd会在午夜之后某个点停止设置the秒标志时调用adjtimex（2）。由于未设置该标志，因此对第554行的检查将不成立，并且不会创建任何计时器，而第598行将把time_state全局变量重置为TIME_OK。这解释了为什么如果在the秒之后用adjtimex（8）检查该标志，仍然会看到the秒标志设置。首先，我毕竟给出了：禁用ntpd，并禁用disable秒标志。

还有一些最后的想法：


Linux厂商都不曾注意到John Stultz的修补并将其应用于其内核:(
John Stultz为什么不提醒某些供应商这是必需的？
我听说过应用the秒时Java进程锁定或旋转的报道。也许我们应该跟随Google的领导，重新考虑如何将leap秒应用于系统：http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html



06/02 John Stultz的更新：

https://lkml.org/lkml/2012/7/1/203

这篇文章分步介绍了为什么leap秒导致futex计时器过早连续地超时，从而增加了CPU负载。

评论

---

感谢您的出色回答。因此，我们的其余服务器都在等待崩溃。可爱。滚动重新开始，我们来了！

–布朗·冈瓦纳（Bron Gondwana）
2012年6月30日20:16在

---

我如何知道adjtimex是否已发布，内核是否在dmesg中打印某些内容？在关闭ntpd之前未崩溃的系统有机会崩溃吗？

–休伯特·卡里奥（Hubert Kario）
2012年6月30日在21:20

---

休伯特（Hubert）：运行“ adjtimex”（通常是单独包装），然后寻找标志16来指示pending秒未决。

–Dominic Cleal
2012年6月30日21:26

---

您会讨厌销售代表上限。

–韦斯利
2012年6月30日22:06

---

@WesleyDavid：不用担心，销售代表上限将在UTC午夜重置。也许。

–男士
2012年6月30日23:01

---

#2 楼

这给我们带来了沉重的打击。重新启动我们的许多主机后，以下结果非常简单且完全有效，无需重新启动主机：

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

仅需重置系统时钟。嘘。我六个小时前所知道的一切。

#3 楼

一个简单的C程序，它清除内核时间状态字段中的the秒位：

 #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之前先停止它，然后在the秒后重新启动ntpd。

#4 楼

死后似乎./lsec无效。

我们看到的是很多softirqd进程吞噬了CPU（通常与Java进程的负载成线性关系）

用ntp已经应用的leap秒来修复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

#5 楼

http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back似乎表明Debian压缩内核无法处理the秒。

此还可以关注comp.protocols.tim.ntp上的线程：https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

也就是说，the秒尚未发生：23:59:60 UTC

最后，https：//access.redhat.com/knowledge/articles/15145表示： the秒发生时，内核会在系统日志中打印一条消息。打印此消息可能会导致内核在Red Hat Enterprise Linux中崩溃。”