题 在闰日期间遇到高速Linux服务器崩溃的其他人?


*注意:如果您的服务器由于内核混乱而仍然存在问题,并且您无法重新启动 - 在您的系统上安装gnu日期时提出的最简单的解决方案是:date -s now。这将重置内核的内部“time_was_set”变量并修复CPU占用java和其他用户空间工具中的futex循环。我已经将这个命令放在我自己的系统上了,确认它正在做它在锡上所说的*

死后

Anticlimax:唯一死的就是我的VPN(openvpn)链接到群集,所以在重新建立的时候有一个激动人心的几秒钟。其他一切都很好,在闰秒过后,ntp开始干净利落。

我已经写完了当天的全部经历 http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

如果你看看Marco的博客 http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second  - 他有一个解决方案,使用ntpd -x在24小时内对时间变化进行分阶段,以避免1秒跳过。这是运行您自己的ntp基础结构的另一种涂抹方法。


就在今天,2012年6月30日星期六 - 在GMT开始之后不久开始。我们在不同的数据中心有一些服务器由不同的团队管理都变暗 - 没有响应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系列内核。

最近的一次撞车是一台机器,运行时间仅为6小时,运行时间为3.2.21。

解决方法

好的人,这是我如何解决它。

  1. 禁用ntp: /etc/init.d/ntp stop
  2. 创建 http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (代码从Marco窃取,请参阅评论中的博文)
  3. fixtime.pl 没有争论,看到有一个闰秒
  4. fixtime.pl 用一个参数来删除闰秒

注意:取决于 adjtimex。我已经把一份挤压了 adjtimex 二进制 http://linux.brong.fastmail.fm/2012-06-30/adjtimex  - 它将在没有依赖于挤压64位系统的情况下运行。如果你把它放在同一个目录中 fixtime.pl,如果系统不存在,将使用它。显然,如果你没有挤64位...找到你自己的。

我要开始吧 ntp 明天再来一次

正如一位匿名用户建议的那样 - 一种替代运行方式 adjtimex 只是自己设定时间,这可能也会清除闰秒计数器。


366
2018-06-30 16:15




今天是第30个闰秒。我犹豫是否暗示这是你的问题,但我会密切关注我的Debian机器。 - jscott
从早上起我们已经失去了来自不同供应商的至少9种不同的debian挤压盒,所有运行库存挤压2.6.32内核。由于控制台消隐,我们无法获得崩溃转储...... - kargig
关于这个lkml发布 lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
谢谢你报道这个!我现在非常非常密切地盯着我的服务器。 - Janne Pikkarainen
LKML线程表明了这一点 date -s "`date`" 帮助 - 它肯定帮助了我。 - Pointy


答案:


当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在此处针对此问题提供了第二篇KB文章: 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 leapsecond公告时检测到挂起。此问题正在及时得到解决。如果您的系统已收到闰秒宣布并没有遇到这个问题,那么他们就不再受到影响了。“

更新:上述语言已从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

如果我这次正确阅读,那么在应用闰秒时会出现另一个死锁是错误的。根据他们的KB条目,这似乎也是Red Hat的观点。但是,如果您已禁用ntpd,请将其禁用另外10分钟,以便在ntpd调用adjtimex(2)时不会遇到死锁。

我们会发现是否还有更多错误:)

POST-LEAP第二次更新:

我花了最后几个小时阅读ntpd和pre-patch(buggy)内核代码,虽然我在这里可能非常错,但我会尝试解释我的想法:

首先,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

内核代码路径大致如下:

  • 第663行 - 开始do_adjtimex例程。
  • 第691行 - 取消任何现有的闰秒计时器。
  • 709行 - 抓住ntp_lock自旋锁(这个锁涉及可能的活锁崩溃)
  • 第724行 - 调用process_adjtimex_modes。
  • 第616行 - 调用process_adj_status。
  • 第590行 - 根据adjtimex(2)调用中设置的标志设置time_status全局变量
  • 第592行 - 检查time_state全局变量。在大多数情况下,请调用ntp_start_leap_timer。
  • 第554行 - 检查time_status全局变量。将设置STA_INS,因此将time_state设置为TIME_INS并调用hrtimer_start(另一个内核函数)以启动闰秒计时器。在创建计时器的过程中,此代码获取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运行其时钟循环过滤器时,都会调用错误代码。

因此,当他们说ntpd设置了闰秒标志时,我认为Red Hat是错误的,系统不会崩溃。我相信运行ntpd的每个系统都有可能在闰秒之前的24小时内每17分钟(或更多)进行一次活锁。我相信这也可以解释为什么这么多系统崩溃了;与一小时的3次机会相比,一次性崩溃的可能性要小得多。

更新:在Red Hat的KB解决方案中 https://access.redhat.com/knowledge/solutions/154713 ,红帽工程师确实得出了同样的结论(运行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,并禁用闰秒标志。

还有一些最后的想法:

  • 没有一个Linux供应商注意到John Stultz的补丁并将其应用到他们的内核:(
  • 为什么John Stultz没有提醒某些需要的供应商?或许活锁的可能性似乎足够低,因此无法保证噪音。
  • 我听说过应用闰秒时Java进程锁定或旋转的报告。也许我们应该跟随谷歌的领先地位并重新思考我们如何将闰秒应用于我们的系统: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 John Stultz的更新:

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

在贴子中为什么闰秒导致futex的定时器过早,不断到期,扣球CPU负载一步一步的演练。


322
2018-06-30 19:56



谢谢你的出色答案。所以我们的其他服务器都在等待崩溃。可爱。滚动重启我们来了! - Bron Gondwana
我怎么知道 adjtimex 已发布,内核是否在dmesg中打印出来?在关闭ntpd之前没有崩溃的系统会有什么机会崩溃? - Hubert Kario
休伯特:运行“adjtimex”(它通常是单独打包)并查找标志16以指示闰秒待处理。 - Dominic Cleal
你会讨厌代表上限。 - Wesley
@WesleyDavid:不用担心,代表将在UTC午夜重置。也许。 - mmyers


这让我们很难受。在重新启动我们的许多主机之后,如果没有主机重启,以下结果非常简单且完全有效:

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

只需重置系统时钟即可。啧。六小时前我已经知道了这件事。


33
2017-07-01 07:49



date -s "`date`" 为我工作。 - Pointy
@DeanB:我在UTC时间凌晨3点发布了重置时钟的功能,不幸的是,它需要一段时间才能得到缓和。我们也开始重启服务器 - Gregor


一个简单的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。


24
2018-06-30 23:13



是什么 (void) argc; 完成?使未使用变量的警告静音?不会用 int main() 完成同样的事情?我并不想成为一名学生,我真的很好奇。 - gparent


事后看来./lsec没有效果。

我们看到的是许多软件进程占用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

18
2017-07-01 03:41



为什么 sntp -s 并不是 ntpdate? - errordeveloper
ntpdate只是sntp的包装器,确定使用ntpdate也没关系。 - Gregor
啊我完全错过了有一个ntpdate包压缩,它实际上是一个二进制文件。我编辑了我的帖子以包含此内容。 - Gregor
我也听过类似的报道来解决这个问题(例如使用 date -s)。听起来这个修复只需要设置系统时间而不是回转它(偏移量很小时的默认ntpd行为)。我猜设置时间会导致内核的内部时间保持机制重置自己。 - Patrick
我的java应用程序CPU使用率也飙升(在softirqd中花费了大量的CPU时间),这就解决了这个问题。 - Hubert Kario


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中崩溃。”


17
2018-06-30 18:47



但是3.2.21内核应该 - 至少有一台崩溃的机器正在运行 - Bron Gondwana
在Bron的一些机器上,我们实际上推出了一个应该正确处理即将到来的闰秒的修复程序。 - cosimo
你可以在某个地方发布修复,以便其他人可以审查/建议想法/尝试吗? - kargig
我没有修复......我只是收集信息。也许应该把这作为对原始问题的评论。 - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/... 包含有关修复它的更多细节 - Bron Gondwana