Em um sistema Ubuntu 10.04, notei os seguintes eventos estranhos de sincronização NTP:
Jul 3 02:19:51 hst ntpd[1432]: no servers reachable
Jul 3 02:36:55 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul 3 02:53:48 hst ntpd[1432]: time reset -10.407942 s
Jul 3 02:53:48 hst ntpd[1432]: kernel time sync status change 6001
Jul 3 02:53:48 hst dovecot: dovecot: Fatal: Time just moved backwards by 10 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jul 3 02:58:37 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul 3 02:58:37 hst ntpd[1432]: kernel time sync status change 2001
Jul 3 03:08:15 hst ntpd[1432]: no servers reachable
Jul 3 03:16:49 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul 3 03:17:01 hst CRON[28221]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 3 03:18:04 hst ntpd[1432]: time reset +10.403648 s
Jul 3 03:22:41 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Onde 91.189.94.4 eurupium.canonical.com e a única linha do servidor ntp.confé:
server ntp.ubuntu.com
A atualização às 2h36 parece bastante falsa porque é cancelada 25 minutos depois.
Quais poderiam ser as possíveis razões para isso?
Eu posso imaginar:
- servidor NTP remoto apenas fornece a hora errada
- problemas de rede (uma alta latência poderia introduzir tais desvios?)
- bug induzido por segundo bissexto (isso deve induzir uma falha, certo?)
Se a primeira alternativa fosse o problema, como posso me proteger contra isso?
O NTPD é inteligente o suficiente para consultar vários servidores NTP (quando várias serverlinhas estão disponíveis ntp.conf) e detectar se respostas diferentes se desviam muito umas das outras?
Responder1
Eu vi entradas de syslog como essa em uma máquina Slackware há alguns anos. Acredito que comprei a máquina em questão em 2002 e a executei praticamente 24 horas por dia, 7 dias por semana, durante anos: era meu servidor SSH, SMTP e HTTP. As falhas do NTP surgiram lentamente e aumentaram gradualmente em frequência.
Eu consertei pela primeira vez trocando a bateria "CMOS RAM", que era uma daquelas baterias CR2032 do tamanho de uma moeda (quarto dos EUA) na placa-mãe.
Depois de mais um ou dois anos de operação, aquela máquina simplesmente parou de marcar o tempo com precisão e eu tive que reiniciar regularmente ntpd. Pelo que entendi, ntpdmantém um "arquivo distorcido" com base em dados anteriores de como o relógio local difere do (s) relógio (s) da rede. Meu palpite é que a placa-mãe em questão nunca teve um clock excelente, e o clock finalmente ficou tão ruim que o “arquivo distorcido” simplesmente não conseguiu acompanhar sua grande variação.