O deslocamento é muito grande; Certifique-se de sincronizar o relógio "one-shot" antes de iniciar o xntpd, por exemplo com rdate ( sudo rdate -nv 2.pool.ntp.org ) ou o próprio utilitário ntptime do xntpd.
Eu tive uma situação ultimamente com um host que precisa de servidores ntp atualizados. Tivemos durante o fim de semana uma queda do nosso roteador de internet. Quando tudo voltou ao normal, nosso aplicativo ainda estava reclamando sobre o NTP.
Descobrimos que o cliente ntp levou 9h para obter a sincronização. Aqui estão os registros do ntpd:
Aug 19 15:31:15 host ntpd[26550]: kernel time sync status 0040
Aug 19 15:31:15 host ntpd[26550]: frequency initialized 97.149 PPM from /tmp/drift
Aug 20 00:29:24 host ntpd[26550]: synchronized to 192.168.10.13, stratum 3
Aug 20 00:29:24 host ntpd[26550]: kernel time sync disabled 0001
Quando o problema ocorreu aqui, está a saída do estado dos pares:
# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
srv1 145.238.203.10 3 u 31 64 377 0.714 -685.16 6.388
srv2 145.238.203.10 3 u 5 64 377 0.652 -1385.7 12.165
Alguém me disse que eu deveria usar configurações de minpoll e maxpoll para resolver esse problema.
O que devo fazer para evitar a sincronização 9H NTP?
O deslocamento é muito grande; Certifique-se de sincronizar o relógio "one-shot" antes de iniciar o xntpd, por exemplo com rdate ( sudo rdate -nv 2.pool.ntp.org ) ou o próprio utilitário ntptime do xntpd.
A outra alternativa é adicionar o seguinte ao ntp.conf:
tinker panic 0
ou adicionando -g às suas opções de inicialização do ntpd.
Isso permitirá que o ntpd lide com o offset, não importando o quão grande ele seja.
Mais uma coisa; dois servidores de tempo é a pior configuração possível para adquirir o tempo. O seu ntpd não fará ideia de qual relógio é melhor quando ele relata tempos diferentes. Use um mínimo de três relógios.
"Um homem com um relógio sabe que horas são. Um homem com dois relógios nunca tem certeza."