Se está ejecutando un servidor estable de Debian (5.0.3) ntpdy conectado a Internet. Aún así, el reloj del sistema está equivocado unos 5 minutos.
$ /etc/init.d/ntp status
NTP server is running..
Partes relevantes (creo) 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
Sé que NTP no necesariamente trae el reloj a tiempo inmediatamente. Aún así, ¿cuántas horas o días debe esperar para esperar razonablemente que NTP haya hecho su trabajo y sincronizado el reloj?
¿Me estoy perdiendo algún otro archivo de configuración u opción, o simplemente estoy haciendo algo mal? ¿Es ntp (en lugar de, por ejemplo, ntpdate ) la herramienta adecuada para esto? ¿Hay alguna forma rápida de verificar si la configuración es correcta y si los servidores NTP elegidos devuelven la hora correcta?
Editar : salida de ntpq -pes:
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
Edición 2 : devuelve el ntpdate -u 0.europe.pool.ntp.orgcomando ( sugerido por brent ) devuelve
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... aunque en otras máquinas ese comando funciona bien. Así que analizaremos la configuración de red / firewall para este servidor en particular (que está en una red diferente, a la que se accede a través de VPN).
Resolución : El culpable no era el firewall local en nuestro servidor, sino la configuración del firewall en algún lugar de la red circundante. Entonces le pedimos al proveedor de alojamiento del servidor que permitiera NTP para nuestras máquinas, y ahora funciona bien. Por ejemplo, ntpq -pahora devuelve:
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
(También cambiamos a los servidores eunet.fi recomendados por la empresa de alojamiento, pero eso no viene al caso). Los comandos en la respuesta de brent fueron útiles porque me hicieron darme cuenta de que el problema estaba en el acceso a la red a los servidores NTP, no en la configuración NTP sí mismo. ¡Gracias a todos!
fuente
Respuestas:
Detenga ntpd, corra
ntpdate -u 0.europe.pool.ntp.org3 veces, inicie ntpd, verifiquentpq -p, demore, compense y jitter no debe ser cero.fuente
ntpdatecomando funciona y sincroniza mi reloj, pero todos los valores permanecen0después de reiniciarntp. ¿Por qué funcionaría si lo hago manualmente, pero no lo usontpd? Estoy en Debian por cierto.Si tuviera que adivinar por qué y suponiendo que tenga conectividad de red y pueda ver su host NTP sin problemas, podría ser que haya derivado a un gran valor. Si la diferencia horaria es mayor que X (lo siento, no recuerdo qué X está fuera de lugar), se imprimirá una advertencia y la hora no se sincronizará. Puede consultar sus mensajes de syslog para casos de esto.
Si este es el caso, detenga NTP, ejecute ntpdate host y reinicie el NTPD, esto forzará una sincronización de tiempo y luego comenzará a mantenerla sincronizada en el futuro, si continúa a la deriva, puede tener un problema de hardware.
fuente
El hecho de que las columnas de "alcance" sean 0 sugiere que no se pudo hablar con los servidores. Iirc gradualmente se desplazan bits para mostrar cómo fueron los últimos 8 intentos (por lo que 377 es bueno, 0 es malo).
fuente