如何解决2012年7月1日增加闰秒后引起linux系统重启问题





国际地球自转和参考坐标系统服务(IERS)将在格林威治时间2012630日午夜增加一闰秒(*关于闰秒的说明),由于Linux kernelPosix关于NTP时间跳变的标准不同,将在201263023:59:59 跳变到201271日后引起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
2012628日当天(北京时间23点以前)先确认ntp服务已同步,然而关闭ntpd服务。
2
201272日(北京时间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服务,可以使用以下命令查询:


  1.  netstat -aunl|grep123       #由于123是ntp启动的端口,所有可以使用netstat来查看ntp的123端口,查看ntp服务是否启动;  
  2.  
  3. ps -ef|grep ntp              #查看ntp服务的进程是否在后台运行;  
  4.  
  5. service ntp status           #使用service来查看ntp服务的启动状态  

下面是我使用这3中方法进行的检测结果

如何解决2012年7月1日增加闰秒后引起linux系统重启问题

可以看得我的服务器里ntp服务正在运行

关闭是方法如下:


  1. 直接杀掉ntp的进程,命令为:kill -9 $(ps -ef|grep ntp|grep -v grep|awk '{print $2}');  
  2. 使用service来关闭ntp,命令为:service ntp stop; 

  1. 关闭后为了保证安全,还需要把ntp开机自动启动给关闭,命令为:chkconfig --level 345 ntp off;

提示:还是建议大家都去一些安全的网站或者论坛里多看一下最新的bug或者安全提示,否则像闰秒增加导致ntp服务锁死,进而导致linux系统重启,会造成很大的影响与损失的,如果你能够提前的了解这些消息并能提前的避免这些问题,及时的通知你的领导,我相信你会赢得你公司与领导的信任的。


 本文转自 reinxu 51CTO博客,原文链接:http://blog.51cto.com/dl528888/911605,如需转载请自行联系原作者


上一篇:SAP WebIDE编辑器的主题设置


下一篇:EIGRP中AD与FD的区别