NTPD意外死亡的可能原因和解决方案

Question

在使用 s3 进行物理文档存储的 Web 应用程序中，我们遇到了 NTP 不断死亡的问题。这似乎每天大约发生一两次。发生这种情况时提供的信息很少，除了 PID 文件存在但在我检查状态时服务已死。

谁能提出NTPD死亡的可能原因？我假设时钟漂移可能导致它死亡，但我也不确定是什么导致了这种情况。有足够的内存和可用磁盘空间。

服务最后一次死亡时，这是输出：

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

Answer 1

我想说没有 1 分钟的方法可以找到确切的原因。

我们之前在 ESXi 环境中也遇到过类似的问题。简而言之，我们发现 ESXi 主机的时钟漂移很大，并且来宾 VM 正在同步来自 ESXi 主机和上游 NTP 服务器的时间。这导致虚拟机上的 NTPd 混淆，因此经常死亡。

我们还发现在一些罕见的情况下，随机丢包也会导致 NTPd 退出，因为您的服务器和上游 NTPd 服务器之间的往返时间用于计算漂移时间。

在以上两种情况下，如果 NTPd 看到大量时间漂移，例如超过 1000 秒，则默认退出。-g 选项会有所帮助。

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

你可以看看系统日志，里面应该有一些话可能会给你一个提示。您还可以监视“ntpq -p”输出以大致了解偏移量是如何发展的。