我注意到我的服务器（Ubuntu 服务器 12.04）正在失去时间。我猜想硬件时钟可能由于 CMOS 电池故障而关闭或死机。我安装了 NTP 以确保偏差得到纠正，但无济于事。一天中它会失去 20 分钟左右。
为了调试，我创建了一个小型 cron 作业来检查远程服务器的时间，我知道它是正确的。该脚本计算本地和远程时间之间的秒差。NTP 服务没有运行在这些测试期间。
结果很有趣。它似乎在一天内多次丢失了恰好 5 分钟的时间。查看此日志（以秒为单位记录与远程服务器的差异）：
Tue Oct 23 03:30:02 CEST 2012: 284
Tue Oct 23 03:35:02 CEST 2012: 284
Tue Oct 23 03:40:01 CEST 2012: 285
Tue Oct 23 03:45:02 CEST 2012: 285
Tue Oct 23 03:50:02 CEST 2012: 285
Tue Oct 23 03:55:02 CEST 2012: 284
Tue Oct 23 04:00:02 CEST 2012: 284
Tue Oct 23 04:05:01 CEST 2012: 285
Tue Oct 23 04:10:01 CEST 2012: 285
Tue Oct 23 04:15:02 CEST 2012: 585
Tue Oct 23 04:20:02 CEST 2012: 584
Tue Oct 23 04:25:02 CEST 2012: 584
Tue Oct 23 04:30:02 CEST 2012: 584
Tue Oct 23 04:35:01 CEST 2012: 585
Tue Oct 23 04:40:01 CEST 2012: 585
Tue Oct 23 04:45:02 CEST 2012: 585
Tue Oct 23 04:50:02 CEST 2012: 584
Tue Oct 23 04:55:02 CEST 2012: 584
Tue Oct 23 05:00:02 CEST 2012: 584
Tue Oct 23 05:05:01 CEST 2012: 585
Tue Oct 23 05:10:01 CEST 2012: 585
Tue Oct 23 05:15:02 CEST 2012: 585
Tue Oct 23 05:20:02 CEST 2012: 584
Tue Oct 23 05:25:02 CEST 2012: 584
Tue Oct 23 05:30:02 CEST 2012: 584
Tue Oct 23 05:35:01 CEST 2012: 585
Tue Oct 23 05:40:01 CEST 2012: 585
Tue Oct 23 05:45:02 CEST 2012: 584
Tue Oct 23 05:50:02 CEST 2012: 584
Tue Oct 23 05:55:02 CEST 2012: 584
Tue Oct 23 06:00:02 CEST 2012: 584
Tue Oct 23 06:05:03 CEST 2012: 584
Tue Oct 23 06:10:02 CEST 2012: 584
Tue Oct 23 06:15:01 CEST 2012: 585
Tue Oct 23 06:20:02 CEST 2012: 584
Tue Oct 23 06:25:02 CEST 2012: 584
Tue Oct 23 06:30:02 CEST 2012: 584
Tue Oct 23 06:35:02 CEST 2012: 584
Tue Oct 23 06:40:02 CEST 2012: 584
Tue Oct 23 06:45:01 CEST 2012: 585
Tue Oct 23 06:50:02 CEST 2012: 584
Tue Oct 23 06:55:01 CEST 2012: 585
Tue Oct 23 07:00:02 CEST 2012: 584
Tue Oct 23 07:05:02 CEST 2012: 584
Tue Oct 23 07:10:02 CEST 2012: 584
Tue Oct 23 07:15:02 CEST 2012: 584
Tue Oct 23 07:20:02 CEST 2012: 584
Tue Oct 23 07:25:02 CEST 2012: 584
Tue Oct 23 07:30:01 CEST 2012: 585
Tue Oct 23 07:35:02 CEST 2012: 584
Tue Oct 23 07:40:02 CEST 2012: 584
Tue Oct 23 07:45:02 CEST 2012: 584
Tue Oct 23 07:50:02 CEST 2012: 584
Tue Oct 23 07:55:02 CEST 2012: 584
Tue Oct 23 08:00:01 CEST 2012: 585
Tue Oct 23 08:05:02 CEST 2012: 584
Tue Oct 23 08:10:02 CEST 2012: 584
Tue Oct 23 08:15:02 CEST 2012: 584
Tue Oct 23 08:20:02 CEST 2012: 584
Tue Oct 23 08:25:02 CEST 2012: 584
Tue Oct 23 08:30:01 CEST 2012: 585
Tue Oct 23 08:35:02 CEST 2012: 584
Tue Oct 23 08:40:02 CEST 2012: 584
Tue Oct 23 08:45:02 CEST 2012: 584
Tue Oct 23 08:50:02 CEST 2012: 584
Tue Oct 23 08:55:02 CEST 2012: 584
Tue Oct 23 09:00:02 CEST 2012: 584
Tue Oct 23 09:05:03 CEST 2012: 584
Tue Oct 23 09:10:02 CEST 2012: 584
Tue Oct 23 09:15:02 CEST 2012: 584
Tue Oct 23 09:20:02 CEST 2012: 584
Tue Oct 23 09:25:02 CEST 2012: 584
Tue Oct 23 09:30:01 CEST 2012: 584
Tue Oct 23 09:35:02 CEST 2012: 584
Tue Oct 23 09:40:02 CEST 2012: 584
Tue Oct 23 09:45:02 CEST 2012: 584
Tue Oct 23 09:50:02 CEST 2012: 584
Tue Oct 23 09:55:02 CEST 2012: 584
Tue Oct 23 10:00:01 CEST 2012: 584
Tue Oct 23 10:05:02 CEST 2012: 584
Tue Oct 23 10:10:07 CEST 2012: 584
Tue Oct 23 10:15:02 CEST 2012: 584
Tue Oct 23 10:20:02 CEST 2012: 884
Tue Oct 23 10:25:02 CEST 2012: 884
Tue Oct 23 10:30:02 CEST 2012: 883
Tue Oct 23 10:35:01 CEST 2012: 884
Tue Oct 23 10:40:02 CEST 2012: 884
Tue Oct 23 10:45:02 CEST 2012: 884
Tue Oct 23 10:50:02 CEST 2012: 884
Tue Oct 23 10:55:02 CEST 2012: 1184
Tue Oct 23 11:00:02 CEST 2012: 1183
Tue Oct 23 11:05:01 CEST 2012: 1184
Tue Oct 23 11:10:02 CEST 2012: 1184
Tue Oct 23 11:15:02 CEST 2012: 1184
Tue Oct 23 11:20:02 CEST 2012: 1184
在我看来，这似乎不是 CMOS 电池故障。但您怎么看？
编辑：
当我启用 NTP 时，这是 ntpq -p 的输出：
remote refid st t when poll reach delay offset jitter
==============================================================================
dns02.wsrs.net .INIT. 16 u - 64 0 0.000 0.000 0.000
brick.steinhoff 71.40.128.157 3 u 1 64 1 144.031 1499785 0.002
chime6.surfnet. .PPS. 1 u - 64 1 22.663 1499789 0.002
ntp0.mediamatic .INIT. 16 u - 64 0 0.000 0.000 0.002
europium.canoni .INIT. 16 u - 64 0 0.000 0.000 0.002
编辑2：
ntpdate ntp.ubuntu.com 之后
remote refid st t when poll reach delay offset jitter
==============================================================================
kvm01.roethof.n 213.154.236.182 3 u 10 64 1 34.918 -1.980 0.002
ntp0.bbactive.e 193.79.237.14 2 u 9 64 1 58.378 6.956 0.002
16-164-ftth.ons 193.79.237.14 2 u 8 64 1 30.202 5.697 0.002
kameli.miuku.ne 62.237.86.238 2 u 7 64 1 106.975 -9.806 0.002
europium.canoni 193.79.237.14 2 u 6 64 1 42.010 6.381 0.002
答案1
我认为硬件时钟已关闭或者可能由于 CMOS 电池故障而失效。
仅当您启动操作系统时才会读取 CMOS 时钟。
我安装了 NTP 以确保漂移能够得到纠正，但无济于事。
NTP 并非旨在纠正巨大的偏移。您可以使用 进行纠正ntpdate，然后启动 ntpd，几个小时后检查ntpq -p并确保您理解它告诉您的内容。然后在 syslog 中查找 NTP 投诉。
NTP 一直在运行，但有时还是会丢失 300 秒
如果是这样，我希望看到 NTP 在系统日志中对此进行评论 - 这将准确地告诉您问题发生的时间。也许这与 cron 作业或某些外部事件相吻合。我会跟进这些线索。我假设您会注意到硬件故障是否会一次冻结系统 5 分钟。
NTP 故障排除
我害怕NTP 故障排除尤其是“已知问题”部分。
监测时间
哈罗德已经有了一个脚本，对于其他人来说，这里有几个想法：
在 badserver 上启用 RFC868 时间协议
vi /etc/xinetd.d/time-stream
# change `disable=yes` to `disable=no`
kill -HUP $(cat /var/run/xinetd.pid)
在 goodserver 上使用 cron 每分钟安排一次
date -u; TZ=utc rdate badserver > /tmp/badserver-time.log
或者更好的是，编写一个脚本，仅记录响应失败或好服务器和坏服务器之间偏移量的较大变化。