Por que o ntpq -pn reporta “Conexão recusada”?

Question

Por que o ntpq -pn reporta “Conexão recusada”?

#1 resposta do (6 votos)

4

Eu configurei recentemente um sistema CentOS 6.x com NTPD em execução e estou encontrando este erro quando executo ntpq -pn :

$ ntpq -pn
ntpq: read: Connection refused

Eu sei que ntpd está funcionando e funcionando por meio do comando ntpstat :

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

Por que ntpq -pn não está funcionando?

ntp centos

por slm 17.02.2017 / 17:28

1 resposta

Tags ntp centos

O que é $ OPTIONS em um arquivo de serviço do systemd? O que são os símbolos de intercalação e as classes de equivalência usadas?

score 6 · Accepted Answer

Você pode fazer a triagem um pouco olhando a saída via strace da seguinte forma:

$ 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

Observe que está usando o ipv6 para se conectar. Basicamente esta linha:

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

O NTPD está ouvindo em uma porta 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

Portanto, parece não estar escutando no ipv6, daí o erro. Podemos resolver isso dizendo ntpq -pn para se conectar explicitamente ao ipv4 da seguinte forma:

$ 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

Muito melhor. E você pode confirmar nossa lógica usando strace novamente:

$ 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)

Observe que o ipv4 usa sa_family=AF_INET , enquanto o ipv6 usa sa_family=AF_INET6 quando o cliente ntpq tenta se conectar ao seu ntpd via UDP na porta 123.

Também podemos usar as opções -4 e -6 para ntpq -pn :

$ 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

Referências

link