web-dev-qa-db-fra.com

Pourquoi ntpq -pn signale "Connexion refusée"?

J'ai récemment configuré un système CentOS 6.x avec NTPD en cours d'exécution et je rencontre cette erreur lorsque j'exécute ntpq -pn:

$ ntpq -pn
ntpq: read: Connection refused

Je sais que ntpd est en place et fonctionne via la commande ntpstat:

$ ntpstat
synchronised to NTP server (204.11.201.12) at stratum 3
   time correct to within 71 ms
   polling server every 256 s

Pourquoi est-ce ntpq -pn Ca ne fonctionne pas?

centosntp
9
slm

Vous pouvez trier cela un peu en regardant la sortie via strace comme ceci:

$ strace ntpq -pn ::1|& grep -i conn
connect(3, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
recvfrom(3, 0x7fffc3365a10, 516, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
write(2, "Connection refused\n", 19Connection refused

Notez qu'il utilise ipv6 pour se connecter. Fondamentalement, cette ligne:

connect(3, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0

NTPD écoute-t-il sur un port ipv6?

$ netstat -taupn|grep udp|grep ntp
udp        0      0 10.22.7.237:123             0.0.0.0:*                               24213/ntpd
udp        0      0 127.0.0.1:123               0.0.0.0:*                               24213/ntpd
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               24213/ntpd

Il ne semble donc pas écouter sur ipv6, d'où l'erreur. Nous pouvons contourner ce problème en disant à ntpq -pn pour se connecter explicitement sur ipv4 à la place comme ceci:

$ ntpq -pn 127.0.0.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+69.89.207.199   212.215.1.157    2 u  209  256  377   43.582    2.768   0.076
-72.5.72.15      10.3.255.0       3 u  217  256  377   68.627   -1.833   4.388
*204.11.201.12   66.220.9.122     2 u  244  256  377   61.928   -0.712   0.234
+108.59.2.24     130.133.1.10     2 u  178  256  377    1.824    3.256   0.111

Bien mieux. Et vous pouvez confirmer à nouveau notre logique en utilisant strace:

$ strace ntpq -pn 127.0.0.1|& grep -i conn
connect(3, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
connect(4, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(4, {sa_family=AF_LOCAL, Sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)

Notez que ipv4 utilise sa_family=AF_INET alors que ipv6 utilise sa_family=AF_INET6 lorsque le client ntpq tente de se connecter à votre ntpd via UDP sur le port 123.

Nous pouvons également utiliser le -4 et -6 passe à ntpq -pn ainsi que:

$ ntpq -pn -4
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+69.89.207.199   212.215.1.157    2 u  235  256  377   43.582    2.768   0.047
-72.5.72.15      10.3.255.0       3 u  248  256  377   68.627   -1.833   4.417
*204.11.201.12   66.220.9.122     2 u  265  256  377   61.802   -0.765   0.198
+108.59.2.24     130.133.1.10     2 u  212  256  377    1.824    3.256   0.097

Références

11
slm

J'ai eu le même problème récemment avec CentOS7. ntpq -p afficherait "lecture: connexion refusée", ainsi que de nombreuses autres commandes dans le débogage ntp telles que "liste d'horloge" et quelques autres. NTP que j'ai définis dans ntp.conf ont été ignorés. Voici quelques autres sorties notables:

[root@server ~]# ntpstat
synchronised to NTP server (69.164.198.192) at stratum 3
   time correct to within 56 ms
   polling server every 1024 s

[root@server ~]# ntpdate
14 Oct 00:02:14 ntpdate[21443]: no servers can be used, exiting

[root@server ~]# systemctl status ntp
Unit ntp.service could not be found.

[root@server ~]# systemctl status ntpd
 ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

ntpq> version
ntpq [email protected] Thu Aug  8 11:48:03 UTC 2019 (1)

ntpq> clocklist
ntpq: read: Connection refused

ntpq> cooked
Output set to cooked

ntpq> readlist
ntpq: read: Connection refused

Quand j'ai vérifié l'IP du serveur NTP qu'il utilisait, c'était toujours quelque chose d'ARIN (?) Ou d'un grand fournisseur comme Level3. Je ne pouvais pas choisir le serveur, mais les serveurs que j'utilisais semblait correct. Mais il ne me permettait toujours pas de choisir mes propres serveurs, peu importe ce que je faisais dans /etc/ntp.conf.

J'ai commencé à soupçonner que j'avais un mauvais programme d'une manière ou d'une autre, et j'ai commencé à soupçonner le dépôt epel que j'avais chargé car j'avais besoin d'autres programmes à partir de là.

Effectivement, j'ai effectué ce qui suit et résolu le problème:

yum remove ntp
yum install ntp --disablerepo=epel

Il a réinstallé, maintenant ntpq -p fonctionne et systemctl status ntpd apparaît comme:

[root@server ntpstats]# systemctl status ntpd
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-10-14 22:14:44 CDT; 3s ago

Enfin, les serveurs que j'ai définis dans /etc/ntp.conf sont utilisés.

Je ne sais pas comment convaincre Word que leur ntp CentOS7 est en quelque sorte arrosé, peut-être que quelqu'un le verra et fera un rapport.

Notez que epel et le référentiel CentOS montraient la même version: ntp-4.2.6p5-29.el7.centos.x86_64.

2
ppr