6月30日将迎来人类迎来史上第26次闰秒可引起部分linux系统重启

国际地球自转和参考坐标系统服务(IERS)将在格林威治时间2015年6月30日午夜增加一闰秒（维基百科关于闰秒的说明），由于Linux kernel和Posix关于NTP时间跳变的标准不同，将在2015年6月30日23:59:59 跳变到2015年7月1日后引起ntpd进程锁死，从而造成部分开启ntp服务的linux系统重启。

另外，群友“沈阳-任浩”补充几点说明关于调整闰秒可能导致 kernel hang 住的问题：
1. RHEL3/RHEL6所有系统不受该问题的影响。
2. RHEL4内核版本在kernel-2.6.9-89.EL （RHEL4.8）及以上，RHEL5内核版本在
kernel-2.6.18-164.el5（RHEL5.4）及以上的系统不受该问题的影响。
3. 其他RHEL4和RHEL5的系统有可能发生该问题，建议尽快升级至上述版本或更高
版本以规避该问题。

a. 若由于其他原因实在无法进行内核升级，且应用对时间的敏感度不是非常高，
容许有1秒钟的差值，有如下建议：
对于使用ntpd服务进行时间同步的RHEL，至少提前1天停止ntpd服务。并确保每台
机器上安装的tzdata的版本低于2011n-2(不 包含该版本)。
对于不使用ntpd服务进行时间同步的RHEL，确保每台机器上安装的tzdata的版本低
于2011n-2(不包含该版本)。
从而使系统不进行闰秒调整，待该事件完成之后，再可启动ntpd服务进行同步，或
者手动修改时间为正确时间。

提示：对于内部的以RHEL作为NTP服务器的系统，它是NTP服务器的同时，也是使用
ntpd服务与更上层NTP服务器进行时间同步的客户端， 故上述方法也适用于该系统。
b. 若由于其他原因实在无法进行内核升级，但应用对时间的敏感度非常高，不容
许有1秒钟的差值，则有可能发生kernel hang住的问题，尽管这个可能性是非常小的。
如果发生问题，可考虑重启该系统恢复。

根据这个情况，我有找到了相应的解决方法：
如果您的相关设备是使用Linux kernel 为2.6.18-164.e15以前的Linux系统，请做如下预防工作：
1、2012年6月28日当天（北京时间23点以前）先确认ntp服务已同步，然而关闭ntpd服务。
2、2012年7月2日（北京时间8点以后）当天开启ntpd服务，并确认ntp服务已同步。
对照上面的解决方法，我检测了我所有服务器（100多台，累死了），发现rhel5.4服务器的内核都为2.6.18-164.e15，但都没有开启ntp服务，而所有的SUSE Linux Enterprise Server 10 的linux系统里内核都是2.6.16.60-0.54.5-smp，就1台数据库服务器启动了ntp服务，下面演示我是如何如何的解决这个问题的：
1、先查看服务器是否有开启ntp服务，可以使用以下命令查询：
netstat -aunl|grep123 #由于123是ntp启动的端口，所有可以使用netstat来查看ntp的123端口，查看ntp服务是否启动；

ps -ef|grep ntp #查看ntp服务的进程是否在后台运行；

service ntp status #使用service来查看ntp服务的启动状态
下面是我使用这3中方法进行的检测结果

加载中…

可以看得我的服务器里ntp服务正在运行
关闭是方法如下：
直接杀掉ntp的进程，命令为：kill -9 $(ps -ef|grep ntp|grep -v grep|awk ‘{print $2}’)；
使用service来关闭ntp，命令为：service ntp stop；
关闭后为了保证安全，还需要把ntp开机自动启动给关闭，命令为：chkconfig –level 345 ntp off；