这是在RHEL 5.5中。
首先，ntpdate到远程主机工作：
$ ntpdate XXX.YYY.4.21 24 Oct 16:01:17 ntpdate[5276]: adjust time server XXX.YYY.4.21 offset 0.027291 sec 其次，这是我的/etc/ntp.conf中的服务器行。 所有的restrict线都已被注释掉以进行故障排除。
server 127.127.1.0 server XXX.YYY.4.21
我执行service ntpd start并检查ntpq ：
$ ntpq ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 5 l 36 64 377 0.000 0.000 0.001 timeserver.doma .LOCL. 1 u 39 128 377 0.489 51.261 58.975 ntpq> opeer remote local st t when poll reach delay offset disp ============================================================================== *LOCAL(0) 127.0.0.1 5 l 40 64 377 0.000 0.000 0.001 timeserver.doma XXX.YYY.22.169 1 u 43 128 377 0.489 51.261 58.975
XXX.YYY.22.169是我正在处理的主机的地址。 对ntp.conf文件中的IP地址进行反向查找，可以validationntpq输出是否正确命名了远程服务器。 然而，正如你所看到的，它似乎只是滚动到我的.LOCL。 时间服务器。 此外， ntptrace只是返回本地时间服务器，并且ntptrace XXX.YYY.4.21超时。
$ ntptrace localhost.localdomain: stratum 6, offset 0.000000, synch distance 0.948181 $ ntptrace XXX.YYY.4.21 XXX.YYY.4.21: timed out, nothing received ***Request timed out
这看起来像我的ntp守护进程只是查询自己。
我正在考虑在testingnetworking时间服务器和公司networking时间服务器之间的路由器 – 我不控制源端口上的阻塞的可能性。 （我认为ntpdate在端口123上发送，这是为什么我不能在ntpd运行时使用它）。我有电子邮件进入networking人员检查。
最后， telnet XXX.YYY.4.21 123永远不会超时或完成连接。
问题：
我在想什么？
还有什么我可以检查，试图找出这个连接失败的地方？
将strace ntptrace XXX.YYY.4.21显示源端口ntptrace发送？ 我可以解构大多数strace调用，但我无法弄清楚这个数据的位置。
如果我不能直接检查我的testingnetworking和时间服务器之间的网关路由器，我该如何build立证据来certificate它负责这些断开连接？ 或者，我怎样才能排除？
reach栏中的377表示连接正常; 由于NTP是UDP，因此telnet将不会连接。
尝试从您的configuration中删除server 127.127.1.0 – * by *LOCAL(0)告诉我们本地服务器的层数为5用于同步，优先于远端服务器的层数为1; 延迟和偏移都是0.000，可能与此有很大关系。
如果你打算把本地时钟fudge的水平相当一点。 看起来你已经设置为5.我通常将其设置为至less8（ fudge 127.127.1.0 stratum 8 ）。 如果你不欺骗它，你可以像networking上的其他主机那样出现一个primefaces钟。 在我扫描的一个networking中，我发现很多低层服务器宣布的时间通常是几个小时或几天不正确。
谢恩是正确的关于reach价值，这表明你有权访问服务器。 你的时间服务器的高offset和jitter值表明它可能不是很可靠。 它们可能很高，因为你的服务器仍在同步。 poll间隔增加到128的事实表明您的服务器正在获得一致的结果。 它应该逐渐增加到1024秒。
尝试运行一个循环，如：
while sleep 60; do ntpq -n -c peers; done
这会给你一个想法ntp如何工作。 你应该看到它随着时间的推移而稳定。
可以在ntpd上设置一些限制，以限制远程访问服务器的多less信息。 您可能被限制只使用上游服务器作为时间源。
防火墙规则限制stream量到源端口123的stream量是可能的。 这提供了一个工作的ntp设置，但限制了其他工具的访问。 如果可用，某些工具允许您使用端口123作为源端口。 我偏爱在debugging模式下使用ntpdate 。
如果你的上游服务器是你的IP地址的refid是正确的，它似乎是使用你的服务器，因为它是首选的时间源。 尝试将restrict noquery添加到您的configuration。 这可能是你的上游服务器configuration不好。 尝试添加您的路由器和/或名称服务器的来源，我发现他们可以比官方公司服务器更好的来源。
我有同样的问题：
ntpq -p显示达到= 0
然而，1-ntpd正在运行2- ntp.conf有服务器列出3 ntpdate使用这些服务器4 ntpdate -u使用这些服务器5 nc显示TCP端口123在这些服务器上打开6 nc显示UDP端口123是在这些服务器上打开
所以基本上ntpdate的工作，并没有防火墙问题，但ntpq -p显示每个服务器列出达到= 0。
原来是ntp.conf中的限制行。 我只是从ntp.conf中删除所有限制行，并重新启动ntpd，从那里一切工作。
对于那些正在寻求macros伟解决scheme的人，我表示歉意。 这将是俗气。
是的，时间服务器无法访问，出于我无法确定的原因。 好消息是，我所访问的外部DNS服务器之一本身就是服务于NTP数据包的，并且正在连接到该外部时间服务器的tick。 这是一个解决方法，而不是修复。 但是，我会拿我能得到的。
所以最终我只会失去一个服务阶层。
作为一个方面说明，我注册了NTP错误数据库，所以我可以编写增强错误2297 ，要求正确的文档对等的refids .INIT。，.LOCL。和LOCAL（0）。
只是想把我的两美分添加到谷歌的search结果。我遇到了一个主机上的NTP没有绑定到主机的外部接口的问题。 如果你有这个问题，看一下netstat -tulpn的输出。
ntpd的这个实例将不能同步到一个已知的好时间源。
$ sudo netstat -tulpn | grep ntp udp 0 0 127.0.0.1:123 0.0.0.0:* 31316/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 31316/ntpd
这会。
$ sudo netstat -tulpn | grep ntp udp 0 0 192.168.1.15:123 0.0.0.0:* 32294/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 32294/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 32294/ntpd
这是configuration文件尝试限制绑定到IPv4接口只使用0.0.0.0通配符的结果。
$ grep ^interface /etc/ntp.conf interface listen 0.0.0.0
正确的（期望的）configuration如下。
$ grep ^interface /etc/ntp.conf interface listen ipv4 interface ignore ipv6
（或者，删除两个接口configuration选项。）
您还可以检查/etc/sysconfig/ntp或其他等效的configuration来限制接口绑定。