*注意：如果您的服务器仍然由于内核混乱而出现问题，并且您无法重新启动 - 建议在您的系统上安装 gnu date 的最简单解决方案是：date -s now。这将重置内核的内部“time_was_set”变量并修复 Java 和其他用户空间工具中占用 CPU 的 futex 循环。我已经在我自己的系统上跟踪了这个命令，并确认它正在做它在罐头上所说的 *
尸检
虎头蛇尾：唯一死掉的是我的 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 个小时。
解决方法
好吧，这就是我解决它的方法。
- 禁用的 ntp：
/etc/init.d/ntp stop - 创建了http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl（从 Marco 窃取的代码，请参阅评论中的博客文章）
- 没有争论地跑去
fixtime.pl看看有闰秒设置 - 运行
fixtime.pl参数以删除闰秒
注意：取决于adjtimex. 我在http://linux.brong.fastmail.fm/2012-06-30/adjtimexadjtimex上放了一个 squeeze二进制文件的副本——它将运行而不依赖于 squeeze 64 位系统。如果将它放在与 相同的目录中，则在系统不存在时将使用它。显然，如果您没有 squeeze 64 位……找到您自己的。fixtime.pl
我ntp明天要重新开始。
正如一位匿名用户所建议的那样——跑步的另一种选择adjtimex是自己设置时间，这可能也会清除闰秒计数器。