Como devo gerenciar e solucionar problemas de NTP?

Question

Há algum tempo venho lutando com alguns problemas de NTP na rede da minha empresa e estou tendo dificuldades para entender como os comandos se combinam com o serviço. Por exemplo: No /etc/ntp.conf do servidor, há uma linha:

server IP_of_internal_ntp_server

Mas quando digito ntpq -p , ele mostra o IP de um servidor diferente. Além disso, com o tempo aprendi que a maneira de sincronizar novamente a hora de um servidor com o servidor NTP é esta:

service ntpd stop && ntpdate ntp_server && service ntpd start

Minhas perguntas são:

1. Are the ntpd daemon and ntpdate command work together? if so, why do I have to stop the ntpd daemon in order to sync ntp?
2. The ntpq -p command, is it affected by the /etc/ntp.conf file?
3. In some servers a Nagios NTP check is returning NTP OK: Offset unknown while in all other servers I get a proper response and all other servers are configured just the same, why is that?

Obrigado antecipadamente, Itai

Editar # 1: /etc/ntp.conf :

driftfile /var/lib/ntp/drift
fudge   127.127.1.0 stratum 10  
keys /etc/ntp/keys
restrict 0.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 127.0.0.1 
restrict 1.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict -6 ::1
restrict default kod nomodify notrap nopeer noquery
server 127.127.1.0
server 130.117.52.203 

Saída de ntpq -p :

[root@nyproxy15 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 38.74.128.71    .INIT.          16 u    -   64    0    0.000    0.000   0.000
*LOCAL(0)        .LOCL.          10 l   45   64  377    0.000    0.000   0.001
[root@nyproxy15 ~]#

Por favor, ignore o estrato 16, eu sei que ele precisa ser corrigido.

Editar # 2: Eu editei /etc/ntp.conf e comentei as linhas que você mencionou.

[root@nyproxy15 ~]# service ntpd stop ; ntpdate 130.117.52.203 ; service ntpd start
Shutting down ntpd:                                        [  OK  ]
30 Sep 08:16:30 ntpdate[31192]: adjust time server 130.117.52.203 offset -0.078324 sec
ntpd: Synchronizing with time server:                      [  OK  ]
Starting ntpd:                                             [  OK  ]
[root@nyproxy15 ~]# ntpq -p
localhost.localdomain: timed out, nothing received
***Request timed out
root@nyproxy15 ~]# ps -ef |grep ntp
root     31210     1  0 08:16 ?        00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid

Editar # 3:

Parece que, agora, após alguns minutos, ntpq -p retorna a resposta correta:

[root@nyproxy15 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*130.117.52.203  46.4.54.78       3 u    9   64  377   80.633   -9.950   1.420
[root@nyproxy15 ~]#

    

Answer 1

Se você quer que um servidor NTP faça alguma coisa confiável, você não precisa mentir sobre a confiabilidade de seu próprio relógio; as linhas

server 127.127.1.0

e

fudge 127.127.1.0 stratum 10

faça exatamente isso e parece que se livrar deles corrigiu as coisas.

Quanto a parar ntpd antes de forçar brute o tempo com ntpdate , meu entendimento é que existe uma única estrutura dentro do kernel para brincar com o relógio, e ntpd fica sobre ele (para distorcer o tempo, se necessário). Enquanto estiver lá, ntpdate não pode dar uma olhada; por isso é necessário tirá-lo da imagem por tempo suficiente para que ntpdate funcione.

Mas meu entendimento é estritamente de executar servidores de pool; Eu não sou um programador de kernel, e posso estar errado sobre isso.