Pare o ntpd, execute ntpdate -u 0.europe.pool.ntp.org 3 vezes, inicie o ntpd, verifique o ntpq -p , o atraso, o deslocamento e o jitter devem ser diferentes de zero.
Um servidor Debian Stable (5.0.3) está executando ntpd e conectado à internet. Ainda assim, o relógio do sistema está cerca de 5 minutos errado.
$ /etc/init.d/ntp status
NTP server is running..
Partes relevantes (eu acho) de /etc/ntp.conf :
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Eu sei que o NTP não necessariamente traz o relógio a tempo imediatamente. Ainda assim, quantas horas ou dias você precisa esperar para esperar que o NTP tenha feito seu trabalho e sincronizado o relógio?
Eu estou faltando algum outro arquivo de configuração ou opção, ou apenas fazendo algo errado? É ntp (em vez de, por exemplo, ntpdate ) a ferramenta certa para isso? Existe alguma maneira rápida de verificar se a configuração está correta e se os servidores NTP escolhidos retornam a hora correta?
Editar : a saída de ntpq -p é:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000
sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Editar 2 : Acontece o comando ntpdate -u 0.europe.pool.ntp.org ( sugerido pelo brent ) retorna
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... mesmo que em outras máquinas esse comando funcione bem. Então, vamos analisar as configurações de rede / firewall para esse servidor específico (que está em uma rede diferente, acessada por VPN).
Resolução : O culpado não era o firewall local em nosso servidor, mas as configurações do firewall em algum lugar da rede ao redor. Por isso, pedimos ao provedor de hospedagem do servidor para permitir NTP para nossas máquinas, e agora funciona bem. Por exemplo, ntpq -p agora retorna:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001
ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001
ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(Também mudamos para servidores eunet.fi recomeçados pela empresa de hospedagem, mas isso não vem ao caso.) Os comandos em resposta do brent foram úteis porque me fizeram perceber que o problema estava no acesso de rede aos servidores NTP, não no NTP configuração em si. Obrigado a todos!
Se eu tivesse que adivinhar o porquê e supondo que você tem conectividade de rede e pode ver o seu host NTP sem um problema, então pode ser que você tenha derivado para um grande valor. Se a diferença de tempo for maior que X (Desculpe, não me lembro do que o X é improvisado), então um aviso será impresso e o horário não será sincronizado. Você pode verificar suas mensagens do syslog para casos deste.
Se este for o caso, pare o NTP, execute o host ntpdate e reinicie o NTPD, isso forçará uma sincronização de tempo e então começará a mantê-lo em sincronia, se você continuar a se movimentar, poderá ter um problema de hardware.
As colunas "reach", com 0, sugerem que não foi possível falar com os servidores, pois gradualmente os bits são transferidos para mostrar como foram as últimas 8 tentativas (377 é bom, 0 é ruim).