☰

¿Cuáles son las posibles razones de la sincronización NTP errática?

tag-icon • tag-icon ubuntu ntpd ntp clock
¿Cuáles son las posibles razones de la sincronización NTP errática?

En un sistema Ubuntu 10.04 noté siguientes eventos extraños de sincronización 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

Donde 91.189.94.4 europium.canonical.com y la única línea del servidor ntp.confes:

server ntp.ubuntu.com

La actualización del minuto 2:36 parece bastante falsa porque se cancela 25 minutos después.

¿Cuáles podrían ser las posibles razones para esto?

Puedo pensar en:

  • El servidor NTP remoto simplemente proporciona la hora equivocada
  • Problemas de red (¿podría una alta latencia introducir tales desviaciones?)
  • Error inducido por el segundo intercalar (esto debería provocar un bloqueo, ¿verdad?)

Si la primera alternativa fue el problema, ¿cómo puedo protegerme contra esto?

¿NTPD es lo suficientemente inteligente como para consultar varios servidores NTP (cuando serverhay varias líneas disponibles en ntp.conf) y detectar si las diferentes respuestas se desvían demasiado entre sí?

Respuesta1

He visto entradas de syslog como esa en una máquina Slackware hace unos años. Creo que compré la máquina en cuestión en 2002 y la ejecuté prácticamente las 24 horas del día, los 7 días de la semana durante años: era mi servidor SSH, SMTP y HTTP. Las fallas del NTP se produjeron lentamente y aumentaron gradualmente en frecuencia.

Lo arreglé la primera vez cambiando la batería "CMOS RAM", que era una de esas baterías CR2032 del tamaño de una moneda (un cuarto de dólar estadounidense) en la placa base.

Después de uno o dos años más de funcionamiento, esa máquina dejó de marcar el tiempo con precisión y tuve que reiniciarla periódicamente ntpd. Según tengo entendido, ntpdmantiene un "archivo sesgado" basado en datos anteriores sobre cómo el reloj local difiere de los relojes de la red. Mi suposición fue que la placa base en cuestión nunca tuvo un gran reloj, y el reloj finalmente se volvió tan malo que el "archivo sesgado" simplemente no pudo seguir el ritmo de su variación salvaje.

información relacionada