我们使用Amazon 7( CentOS )提供Amazon实例。但也许这并不是特定于系统
几天前,系统时钟(日期)开始加速。如果我们同步硬件时钟(hwclock),大约10-20分钟后,系统时钟(日期)将提前48秒。And 48 secs offset is the max value。几个小时后,它也将领先48秒。
我知道一点点偏移是正常的。但在10-20分钟内抵消48秒是不正常的.我还知道,有一些文件和lib,比如adjtimex,可以使用"delta“值并调整系统时间,但在我的例子中,当进程达到大约48秒时,加快进程停止。因此,hwclock将打印例如12:00:00,日期将打印12:00:48。
我试过:
ntpdate pool.ntp.org安装ntpdate和同步时间hwclock --hctosys从硬件时钟设置系统时间。还在同步时间(日期)和ntpdate之后尝试了hwclock --systohc。/etc/sysconfig/clock,并将"HWCLOCK_ADJUST“参数设置为true。也尝试用false值/etc/adjtime左右,其中包含UTC和零值。但运气不好。
在时间同步之后,我运行下一个代码:$ while true; do ntpdate pool.ntp.org; sleep 60; done
16 Jan 15:29:45 ntpdate[20656]: step time server 129.250.35.251 offset -4.977822 sec
16 Jan 15:30:46 ntpdate[20743]: step time server 129.250.35.251 offset -5.117517 sec
16 Jan 15:31:48 ntpdate[20813]: step time server 74.117.214.3 offset -4.853926 sec
16 Jan 15:32:50 ntpdate[20890]: step time server 23.239.26.89 offset -5.583270 sec
16 Jan 15:33:51 ntpdate[20941]: step time server 74.117.214.3 offset -4.983483 sec
16 Jan 15:34:53 ntpdate[20994]: step time server 12.167.151.1 offset -5.150401 sec
16 Jan 15:35:54 ntpdate[21080]: step time server 173.255.206.154 offset -5.256357 sec
16 Jan 15:37:03 ntpdate[21155]: adjust time server 12.167.151.1 offset 0.011276 sec
16 Jan 15:38:09 ntpdate[21205]: adjust time server 108.61.56.35 offset -0.019818 sec
16 Jan 15:39:16 ntpdate[21241]: adjust time server 108.61.56.35 offset -0.285154 sec
16 Jan 15:40:18 ntpdate[21660]: step time server 108.61.56.35 offset -5.227262 sec
16 Jan 15:41:19 ntpdate[21706]: step time server 108.61.73.244 offset -5.474606 sec
16 Jan 15:42:20 ntpdate[21756]: step time server 108.61.73.244 offset -5.286961 sec
16 Jan 15:43:22 ntpdate[21791]: step time server 108.61.73.244 offset -4.808674 sec
16 Jan 15:44:29 ntpdate[21885]: adjust time server 96.244.96.19 offset -0.010287 sec
16 Jan 15:45:36 ntpdate[21952]: adjust time server 96.244.96.19 offset -0.000296 sec
16 Jan 15:46:43 ntpdate[22013]: adjust time server 96.244.96.19 offset -0.012838 sec
16 Jan 15:47:51 ntpdate[22126]: adjust time server 198.206.133.14 offset -0.347436 sec
16 Jan 15:48:53 ntpdate[22220]: step time server 198.206.133.14 offset -5.570427 sec
16 Jan 15:49:57 ntpdate[22300]: step time server 198.206.133.14 offset -5.229636 sec
16 Jan 15:50:58 ntpdate[22367]: step time server 104.131.53.252 offset -5.466987 sec
16 Jan 15:52:00 ntpdate[22407]: step time server 104.131.53.252 offset -5.298659 sec
16 Jan 15:53:01 ntpdate[22462]: step time server 104.131.53.252 offset -5.127748 sec
16 Jan 15:54:03 ntpdate[22578]: step time server 129.6.15.30 offset -5.014787 sec
16 Jan 15:55:05 ntpdate[22617]: step time server 129.6.15.30 offset -5.144181 sec
16 Jan 15:56:06 ntpdate[22694]: step time server 129.6.15.30 offset -5.436509 sec
16 Jan 15:57:08 ntpdate[22733]: step time server 96.238.43.39 offset -5.038639 sec谁能告诉我这是怎么回事?这是否意味着系统时钟在大约3-4分钟内正常工作?在这些日志之前,我认为它的速度总是高达48秒。日志不是每隔60秒打印一次的原因,因为ntpdate会工作几秒钟,而同步之后会写入这些文本。
我们通过将ntpdate (ntp)作为自动同步日期的服务来解决这个问题。
“突如其来的巨大加速”的可能原因是什么?
如果这不是一个常见的问题,我们将联系亚马逊支持寻求帮助。
发布于 2018-01-17 13:35:57
这个问题可能是在一个管理程序中;它可能是时钟偏离了48;它发生了(而且不是一个问题唯一的AWS)。
也有一个Xen错误,不知道现在是否适用。( AWS没有迁移到kvm吗?)
亚马逊建议人们安装与他们的NTP服务器同步的chrony。看看EC2 -为您的Linux实例设置时间
如:
sudo yum erase ntp*
sudo yum install chrony使用以下方法创建/etc/chrony.conf:
server 169.254.169.123 prefer iburst最后:
sudo service chronyd start根据@jordanm的注释,也可以尝试的一件事是停止/启动EC2服务器。你可能会很幸运,让它在没有时钟倾斜的情况下在另一个系统管理程序中运行。
如果这些行为仍然不能解决问题,我会与亚马逊开一张票。
https://unix.stackexchange.com/questions/417772
复制相似问题