ntpd 在 0.0.0.2 上獲得“連接：無效參數”
看來 pool.ntp.org 的回复最近發生了變化。這讓我的 CentosOS 6 ntp 伺服器不開心。
$ host pool.ntp.org pool.ntp.org has address 0.0.0.2 pool.ntp.org has address 83.209.8.142 pool.ntp.org has address 130.236.254.17 pool.ntp.org has address 195.178.181.98 $ /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org can't create socket connection# $ strace -f /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org ... connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("130.236.254.17")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("195.178.181.98")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5 connect(5, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("0.0.0.2")}, 16) = -1 EINVAL (Invalid argument) fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6571c5b000 write(1, "can't create socket connection", 30can't create socket connection) = 30 exit_group(3) = ? +++ exited with 3 +++正如現代 Ubuntu 所說，似乎對此達成了普遍共識：
$ ping 0.0.0.2 connect: Invalid argument我認為 0.0.0.2 是有效 IP？
更新
這個問題確實是周期性的，並且已經持續了好幾天（根據我的 nagios，自 2015 年 12 月 20 日以來）：
[12:40] host pool.ntp.org pool.ntp.org has address 194.71.144.71 pool.ntp.org has address 79.136.86.176 pool.ntp.org has address 83.209.8.142 pool.ntp.org has address 178.73.198.130 [13:09] host pool.ntp.org pool.ntp.org has address 194.71.144.71 pool.ntp.org has address 0.0.0.2 pool.ntp.org has address 178.73.198.130 pool.ntp.org has address 192.36.143.130我想有某種排名戰正在進行。
更新 2
對於感興趣的人，當從瑞典查詢 pool.ntp.org 的 DNS RR 時會出現此問題。
所有的
0.0.0.0/8都是保留的，所以這絕對不是 ntp 伺服器的有效 IP。您可以查看IANA 系統資料庫以獲取更多資訊。您應該送出一些錯誤報告。反對
pool.ntp.org，因為他們應該在允許 IP 地址進入池之前驗證 IP 地址的有效性。反對check_ntp_time，因為即使出現無效地址，它也不應該死。相反，它應該嘗試它獲得的三個有效 IP 地址。
在您列出的四台伺服器中，三台位於池中並且具有有效的伺服器監控頁面：
http://www.pool.ntp.org/scores/83.209.8.142
http://www.pool.ntp.org/scores/130.236.254.17
http://www.pool.ntp.org/scores/195.178.181.98
另一種是非法的，一種是不：
http://www.pool.ntp.org/scores/0.0.0.2
正如 kasperd 所指出的，該 A 記錄上返回的 RR 是循環負載平衡的，因此我們無法判斷您的上游 DNS 是否對您撒謊，或者非法地址暫時進入池中。我從作為池管理員的經驗中知道，一個伺服器必須具有高可用性，並且因此得到監控系統的良好評分，才能包含在池中。因此，我個人懷疑無法訪問的地址是否會進入池中，並懷疑這是上游 DNS 故障。但除非你能可靠地重現結果，否則我懷疑我們永遠不會知道。
我突然想到，如果
pool.ntp.org使用 DNSSEC 簽名，我們將立即能夠判斷這是記憶體中毒問題還是池中垃圾問題。如果我有幾分鐘的空閒時間，我可能會在池伺服器的管理員列表中提出這個問題。編輯：我已經在管理員列表上提出了這個問題，並且已經有一個獨立的確認，這個地址似乎確實進入了池，即使它顯然不應該。看這個空間，我猜。
編輯2：顯然，這是一個真正的錯誤，現在已經修復。我同意 kasperd 的觀點，即值得追隨外掛的作者，以使外掛更加健壯，可以在池中胡扯。