在a日第二天，是否有人遇到Linux服务器崩溃率很高的情况？
*注意：如果您的服务器由于内核混乱而仍然存在问题，并且您无法重新引导-建议在系统上安装gnu date的最简单解决方案是：date -s now。这将重置内核的内部“ time_was_set”变量，并修复Java和其他用户空间工具中CPU占用的futex循环。我已经将此命令放在我自己的系统上，并确认它正在执行其在锡盒上所说的内容* 姿势 Anticlimax：唯一导致死亡的是我到集群的VPN（openvpn）链接，因此重新建立它的过程令人兴奋。其他一切都很好，the秒过去后，启动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系列内核。 最近的崩溃是一台运行3.2.21的机器仅运行了大约6个小时。 解决方法 好的，这是我的解决方法。 禁用的ntp： /etc/init.d/ntp stop 创建了http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl（从Marco窃取的代码，请参阅评论中的博客文章） fixtime.pl毫无争议地跑了看第二飞跃 运行fixtime.pl一个参数以删除the秒 注意：取决于adjtimex。我将压缩adjtimex二进制文件的副本放在http://linux.brong.fastmail.fm/2012-06-30/adjtimex上，它将在不依赖于64位压缩系统的情况下运行。如果将它与放在同一目录中fixtime.pl，则在不存在系统1的情况下将使用它。显然，如果您没有压缩64位的话，那就找到自己的吧。 我ntp明天再开始。 正如一个匿名用户所建议的那样，运行的另一种方法adjtimex是自行设置时间，这大概还会清除the秒计数器。