- 论坛徽章:
- 0
|
如果我们接入了互联网，我们可以通过互联网同步到时间源。
好了。下面我们谈谈闰秒对系统的影响。
从上面的知识我们得知，独立自己一台机器，在没有进行任何时间补丁更新的情况下。
是不会出现闰秒的。因为你根本接受不到 ntp服务器发出的闰秒计划信息。- -b
一些组织报告了在2012年6月30日闰秒之后由有缺陷的软件引起的问题。在报告问题的网站有reddit（Apache Cassandra）
Mozilla（Hadoop）
Qantas Airways
以及运行Linux的各种网站。
旧版本的摩托罗拉Oncore VP，UT，GT和M12 GPS接收器有一个软件错误，如果没有闰秒安排在256周，将导致一天的单一时间戳关闭。 2003年11月28日，这实际发生了。午夜时分，该固件的接收机报告2003年11月29日一秒钟，然后恢复到2003年11月28日。
较旧的Trimble GPS接收器具有软件缺陷，其将在GPS星座开始广播下一个闰秒插入时间（在实际闰秒之前几个月）时立即插入闰秒，而不是等待下一个闰秒发生。这使得接收者的时间在过渡期间暂停一秒钟。
较旧的基准Tymeserve 2100 GPS接收机和Symmetricom Tymeserve 2100接收机也有与旧的Trimble GPS接收机类似的缺陷，时间关闭一秒钟。一旦接收到消息，就应用闰秒的提前通知，而不是等待正确的日期。有针对此问题的固件升级。已经描述和测试了解决方法，但如果GPS系统重播广播，或者设备关闭电源，则问题会再次发生。
闰秒对商业部门的影响被描述为“一场噩梦”。由于金融市场容易受到技术和法律闰年问题的影响，洲际交易所母公司的7家结算公司和11家证券交易所，包括纽约证券交易所，在2015年6月30日的时候停止运营61分钟。
Cisco NEXUS 5000系列操作系统NX-OS（版本5.0,5.1,5.2）的几个版本受到影响。
Google服务器不是在一天结束时插入闰秒，而是在闰秒之前在时间窗口上稍微延长秒数。
因此没有受到影响。
其他的东西我们接触到的机会并不多。
主要对于系统运维的影响来自 linux 服务器。windows不会受到任何系统级影响。
linux受影响的内核版本：
linux-2.6.22 之前内核版本；
linux-2.6.25到2.6.27内核版本；
linux-3.4内核版本；
linux-2.6.32内核版本；
查看内核版本命令
# uname -r
我们说的是内核版本，因此全部使用 linux内核 的系统都会受到其影响。
原理：
在标准的Unix时间里会出现问题。这是由CLOCK_REALTIME系统时钟保持的时间，几乎每个需要知道当前时间的应用程序都会使用。它定义为1970年1月1日00:00:00 UTC后的秒数，但没有闰秒。系统时钟不能有时间23:59:60，因为每分钟有60秒，每天有86400秒，这是系统定义死的。
普通的计算机时钟不够稳定，不能保证时间精确到每年增加一秒或两秒，但是当一个时钟与NTP服务器以毫秒的精度同步时，时钟无法插入闰秒才是一个真正的问题。
当闰秒插入UTC时，系统时钟跳过一秒，因为它不能被表示，并突然超过UTC一秒钟。有几种方式如何可以纠正时钟。
1、最常见的方法是当时钟到达00:00:00 UTC时，简单地将时钟返回一秒钟。这是在Linux内核中实现的，并且默认情况下，向后时间跳跃不是恰好在00:00:00发生，而是在第一次系统时钟更新。时钟重复大部分23:59:59秒，也是从00:00:00秒开始的一小部分。结果是时钟关闭一秒钟一秒钟。
下图显示了NTPf服务如何在2015年6月30日使用默认配置更改的UTC时间的TAI偏移。
这种调整方式我们称其为跳跃式调整
此时 linux 系统会出现一句告警
kernel: [xxxxxx.xxxxxx] Clock: inserting leap second 23:59:60 UTC
闰秒代码从定时器那里中断处理程序， 每次时钟中断触发时会调用 tick_do_update_jiffies 更新 jiffies 的值，而 jiffies 主要记录了系统启动以来产生的处理频次，通过 jiffies/Hz 可以得到系统启动了多少秒。因此在这里需要对 xtime_lock 加入写锁。
闰秒代码调用second_overflow 这个函数处理润秒，
我们截取这个函数确定 时间状态的一段判定，发现，
switch (time_state) {
case TIME_OK: if (time_status & STA_INS) time_state = TIME_INS; else if (time_status & STA_DEL) time_state = TIME_DEL; break;
case TIME_INS: if (xtime.tv_sec % 86400 == 0) { xtime.tv_sec--; wall_to_monotonic.tv_sec++; /* The timer interpolator will make time change gradually instead * of an immediate jump by one second. */ time_interpolator_update(-NSEC_PER_SEC); time_state = TIME_OOP; clock_was_set(); printk(KERN_NOTICE "Clock: inserting leap second 23:59:60 UTC\n"); } break;
case TIME_DEL: if ((xtime.tv_sec + 1) % 86400 == 0) { xtime.tv_sec++; wall_to_monotonic.tv_sec--; /* Use of time interpolator for a gradual change of time */ time_interpolator_update(NSEC_PER_SEC); time_state = TIME_WAIT; clock_was_set(); printk(KERN_NOTICE "Clock: deleting leap second 23:59:59 UTC\n"); } break;
case TIME_OOP: time_state = TIME_WAIT; break;
case TIME_WAIT: if (!(time_status & (STA_INS | STA_DEL))) time_state = TIME_OK; }
这里的clock_was_set() 调用对 xtime_lock 的读锁
尴尬的是 现在 xtime_lock 还处于锁状态，死锁发生。
在之后的patch 里面 Thomas Gleixner 在函数里去掉了 clock_was_set() 函数
问题解决
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -122,7 +122,6 @@ void second_overflow(void)
*/
time_interpolator_update(-NSEC_PER_SEC);
time_state = TIME_OOP;
- clock_was_set();
printk(KERN_NOTICE "Clock: inserting leap second "
"23:59:60 UTC\n");
}
@@ -137,7 +136,6 @@ void second_overflow(void)
*/
time_interpolator_update(NSEC_PER_SEC);
time_state = TIME_WAIT;
- clock_was_set();
printk(KERN_NOTICE "Clock: deleting leap second "
"23:59:59 UTC\n");
}
解决办法。
方法1：
升级内核到高版本。避开以上可能出现问题的版本，一劳永逸。
但是毋庸置疑，升级内核这种方法可能会带来一系列的问题。
特别是升级内核后要重启服务器，有可能升级过程中遇到莫名的问题。
生产系统没有必要冒这么大的风险。
方法2：
因为单机并不受影响，因此，我们只需要在闰秒发生之 前一天 开始将NTP服务停掉。
为什么是前1天，因为闰秒通知和闰秒处理不是同时进行处理的。不是前1分钟关上就可以的。
# service ntpd stop
过了闰秒的时间再开开。
# service ntpd start
方法3：
将NTP服务设置为 slew 模式
原理为： slew 模式并不使用跳跃式修改时间。比如一次调整1秒。
而是每秒调整 0.5ms 来缓慢修正时间。
这样就不会调用郁闷的 TIME_INS ，也就不会调用 clock_was_set() 产生锁冲突了。
当然这个模式不是很好，因为调整的太慢了。差1秒还好。差几十秒能调整出几天去。
在过了闰秒，调回来就好。
设置方法。
修改 /etc/sysconfig/ntpd 文件。在 OPTIONS="-g" 前加上 -x
重启服务。
注意 ，如果是做了集群。。请慎重。。。。
|
|
免费注册
发表于 2016-12-20 01:22
发表于 2016-12-23 15:26
