NTP não atualizando o horário do servidor no CentOS

Question

Eu compilei o ntp para o braço Meu cliente NTP não está atualizando o tempo de qualquer servidor Eu me referi ao post "Por que o ntpd não está atualizando o tempo no meu servidor? (7)" Mas nada funciona .. Aqui está a saída do ntpq -pn

[Tue May 15 13:18:26 root@Unknown:bin]$./ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 125.62.193.121  .INIT.          16 u    -   16    0    0.000    0.000   0.000

Eu aprendi que refid não deve ser ".INIT" e atrasos, offset, valores de jitter não devem ser 0

Ao assistir os registros do ntpd

[Tue May 15 13:19:08 root@Unknown:bin]$tail -f ntp.log
15 May 12:29:35 ntpd[18175]: proto: precision = 1000.000 usec
15 May 12:29:35 ntpd[18175]: ntp_io: estimated max descriptors: 1024, initial socket boundary:
15 May 12:29:35 ntpd[18175]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 1 lo 127.0.0.1 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 2 eth1 173.39.19.72 UDP 123
15 May 12:29:35 ntpd[18175]: peers refreshed
15 May 12:29:35 ntpd[18175]: Listening on routing socket on fd #19 for interface updates

Em uma nota lateral - O ntpupdate -u ntp.ubuntu.com funciona, mas o ntpd não funciona. Meu ntp.conf contém apenas uma linha

server 91.189.94.4 minpoll 4 maxpoll 4

onde acima de IP é para ntp.ubuntu.com.

[Fri May 18 15:12:26 root@Unknown:~]$ping pool.ntp.org
PING pool.ntp.org (202.71.140.36): 56 data bytes
64 bytes from 202.71.140.36: seq=0 ttl=53 time=40.000 ms
64 bytes from 202.71.140.36: seq=1 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=2 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=3 ttl=53 time=39.000 ms

O ping funciona, mas o servidor nunca atualiza o tempo

    

Answer 1

Seu ntpd acredita que o sistema remoto é o stratum 16 (o que significa que ele tem o menor tempo possível). A maioria dos clientes ntp não irá sincronizar com esse sistema. É altamente recomendável usar pool.ntp.org conforme descrito em suas instruções .

Seu exemplo ntp.conf file:

driftfile /var/lib/ntp/ntp.drift

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

Além disso, você nunca deve usar IPs no arquivo de configuração, a menos que o sistema não ofereça suporte à resolução de DNS por meio de alguns requisitos insanos.

Atualização:
O projeto NTP Pool tenta fazer uma suposição semi-inteligente sobre qual servidor de horário ele deve retornar para você. Mas você deve normalmente especificar o país que deseja que os servidores sejam usando o código do país nos nomes de host. Para a Índia seria:

server 0.in.pool.ntp.org
server 1.in.pool.ntp.org
server 2.in.pool.ntp.org
server 3.in.pool.ntp.org

O mesmo desvio, registro e outras opções ainda se aplicam.

    

Answer 2

Seu sistema não está recebendo respostas NTP do servidor que você listou, é o que significa "INIT" na coluna "refid": ele ainda está no estado INITialization - enviando pacotes para obter uma leitura INITial do tempo.

Ping pode funcionar, mas pode ser que um firewall esteja bloqueando pacotes NTP (123 / udp) entre sua máquina e o que você está tentando acessar. Ou pode ser que o seu arquivo ntp.conf tenha uma linha "restrita" que é excessivamente proibitiva, e mesmo se os pacotes estiverem chegando e voltando, eles estão sendo ignorados. Veja esta questão anterior de falha no servidor:

Problema ao sincronizar a hora do servidor com o ntpd

Uma maneira de testar se há um problema de nível de rede com pacotes NTP é executar "ntpdate {server}" como root para ver se isso irá definir o relógio localmente (NB: o ntpd não pode ser executado quando você tentar isto).

Se "ntpdate" não funcionar, significa que algo está bloqueando pacotes NTP. Se "ntpdate" funcionar, mas "ntpd" não é (como a situação atual da questão), significa que há algo mais em sua configuração quebrando as coisas.

Lembre-se, só porque "ping" para outro host funciona, não significa que os serviços naquele host de remoção funcionem. Pode ser que os serviços que você está tentando acessar sejam protegidos por firewall ou os daemons não estejam sendo executados na máquina remota. O ping (e o traceroute) simplesmente estão lá para depurar a conectividade no nível do IP: eles não fazem nada para testar a disponibilidade / acessibilidade do nível de transporte (TCP, UDP).