Похоже, что ответ для pool.ntp.org недавно изменился. Это делает мои ntp-серверы CentosOS 6 недовольными.
$ 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?
ОБНОВИТЬ
Проблема действительно периодическая и продолжается уже несколько дней (с 2015-12-20 по моим nagios):
[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
Для тех, кто заинтересован, эта проблема возникает, когда записи DNS RR для pool.ntp.org запрашиваются из Швеции.
Все 0.0.0.0/8 зарезервирован, так что это определенно не действительный IP-адрес для ntp-сервера. Вы можете проверить Реестр IANA Чтобы получить больше информации.
Вы должны отправить несколько отчетов об ошибках. Один против pool.ntp.org, потому что они должны проверять действительность 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, RR, возвращаемые для этой записи A, являются циклическими с балансировкой нагрузки, поэтому мы не можем сказать, лгал ли вам ваш восходящий DNS-сервер, или же в пул временно попал незаконный адрес. По опыту работы администратором пула я знаю, что сервер должен быть высокодоступным и, следовательно, хорошо оцененным системой мониторинга, чтобы его можно было включить в пул. Поэтому я лично сомневаюсь, что недоступный адрес может попасть в пул, и подозреваю, что это был сбой восходящего DNS. Но если вы не сможете достоверно воспроизвести результат, я сомневаюсь, что мы когда-нибудь узнаем.
Мне приходит в голову, что если pool.ntp.org использовали подписи DNSSEC, мы сразу могли бы определить, была ли это проблема с отравлением кеша или проблема с мусором в пуле. Если у меня будет несколько свободных минут, я могу поднять вопрос в списке администраторов серверов пула.
редактировать: Я поднял вопрос в списке администраторов, и уже получили одно независимое подтверждение того, что этот адрес делает похоже, попадает в бассейн, хотя явно не должно. Я думаю, следи за этим пространством.
Редактировать 2: по-видимому, это была настоящая ошибка, и теперь она исправлена. Я согласен с kasperd в том, что стоит погнаться за авторами плагина, чтобы сделать плагин более устойчивым к тому, чтобы гадить в пуле.
0.0.0.2 является "действительным" само по себе, но может использоваться только как источник адрес в соответствии с RFC1700 следовательно, вы не можете пинговать его.