¿Por qué ntpd no actualiza la hora en mi servidor?

Tengo ntpd ejecutándose en mi servidor. Es toda la configuración predeterminada, excepto que comenté su capacidad de ser un servidor para otras máquinas:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Si corro ntpdate -q ntp.ubuntu.com, me dicen que el reloj de mi máquina está apagado por 7 segundos.

¿Que esta pasando? ¿Cómo puedo diagnosticar lo que está sucediendo? ¿Hay algún registro que pueda activar?

más información # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

más información # 2

Esto es lo que parecía cuando hice la pregunta:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

Y así es como se ve ahora, después de reiniciar ntpd un par de veces (supongo que eso es lo que lo solucionó):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

más información # 3

Desinstalé ntp e instalé openntpd y ejecuté /usr/sbin/ntpd -d, y veo una salida como esta:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Lo que para mí indica claramente que no puedo configurar la hora en mi servidor (aunque, con un ntp regular, parece que a veces se actualiza ...).

más información # 4

Mi proveedor de VPS dice:

Los núcleos más recientes no deberían bloquear su sistema en el reloj de nuestro dom0, para estar seguros, puede configurar xen.independent_wallclock = 1 en su sysctl.conf.

Lo que supongo que aún no aborda el problema de que el VPS necesite una CPU disponible para hacer los cálculos de sincronización correctos.

Puede habilitar el inicio de sesión en ntpd agregando esto a ntp.conf:

logfile /var/log/ntpd.log

Fuente: manual ntp

Si desactiva ntpd, ¿puede actualizar el reloj por línea de comando? Si ejecuta el comando ntpdate y recibe un error como este:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Esto significa que probablemente esté en un VPS y, en ese caso, no puede modificar el reloj del sistema; esto solo se puede hacer en la máquina host.

Muy bien amigos, en el tiempo transcurrido desde que hice esta pregunta, reinstalé ntp con la configuración predeterminada del proveedor (Ubuntu 10.0.4) y la dejé correr por unos días. Al momento de escribir esto, ntpdate -q ntp.ubuntu.commuestra que mi tiempo es exacto dentro de 0.000216 segundos. Entonces, los problemas que tenía debían haber estado con mi configuración personalizada (donde estaba tratando de hacer imposible que los hosts externos consultaran mi servidor, lo que ya estoy haciendo con mi firewall, por lo que no estoy demasiado preocupado). Aquí está Ubuntu 10.0.4 ntp.conf en su totalidad, con comentarios eliminados:

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 ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Agradezco sus comentarios sobre cómo podría mejorarse esta configuración.

También hice un ticket con mi proveedor de VPS pidiéndoles una recomendación detallada sobre lo mejor que se puede hacer. Los señalé a este hilo, y alguna otra documentación que indica que tal vez la asignación de la CPU podría causar un problema de sincronización. Aquí está lo que dijeron:

Los núcleos más recientes no deberían bloquear su sistema en el reloj de nuestro dom0, para estar seguros, puede configurar xen.independent_wallclock = 1 en su sysctl.conf. Esto asegurará que la instancia del servidor no siga el reloj en el servidor host.

y:

Creo que puede estar entendiendo mal el grado exacto en que este problema afecta a los clientes NTP en un entorno virtualizado. En mi experiencia en un sistema virtualizado en un host Xen (como nuestra configuración en Rackspace Cloud), la inexactitud heredada al no tener un reloj del sistema dedicado para procesar las interrupciones equivale a fracciones de segundo, incluso en sistemas altamente cargados. NTP maneja fácilmente esta leve imprecisión incluso si solo está configurada para actualizar la hora de los servidores una vez al día (o incluso menos frecuente que eso).

Uno de sus comentarios dice que se está ejecutando en un vhost. En este caso, probablemente no tendrá mucho éxito porque el sentido del tiempo de su vhost dependerá tanto del host real en el que se esté ejecutando como de cuán ocupado esté en general el vhost.

Dependiendo de la virtualización utilizada, es posible que el vhost no obtenga una parte constante de interrupciones en un período de tiempo determinado. Esto hará que el reloj funcione más rápido o más lento de lo que realmente está sucediendo. Dado que ntp está tratando de medir los cambios bajo el supuesto de que su reloj tiene una velocidad fija más rápida o más lenta que el resto del mundo, esta aceleración y desaceleración generará ajustes ntp y probablemente finalmente se rendirá, con el resultado que ntp -npmuestra los servidores de tiempo que ntp ha considerado inadecuados.

Su mejor opción si este es el caso es probablemente una fuerza bruta de rdate -s $servervez en cuando (como cada seis horas) para tirar del reloj por la nariz para que no se desvíe excesivamente de la sincronización. Pero la precisión de grano fino probablemente esté fuera de alcance.

Cosas que encontré en el pasado, cuando usaba ntpd en lugar de openntpd:

1. Debe permitir el acceso a localhost para que ntpd se inicie correctamente y realmente haga cosas

   restrict 127.0.0.1
   restrict ::1
   

2. Aunque puede usar nombres de host para las reglas del servidor, abrir agujeros de respaldo para hablar con esos servidores significa usar los restrictque requieren direcciones IP, por lo que terminé teniendo que usar IP para todo de todos modos.

3. No menciona el uso restrictpara abrir el acceso a sus servidores. Eso es un problema Pruebe bloques como los siguientes:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Necesita múltiples pares o servidores para ntpd, ya que intenta usar la votación por reglas mayoritarias para tratar con un mal actor. Por lo tanto, un mínimo de 4, para poder tener una mayoría cuando pierdes uno, preferiblemente 5.

5. Para bloquear el acceso predeterminado, podría usar:

   restrict default notrust nomodify
   

   para poder seguir consultando, pero terminé usando restrict default ignorecomo lo hace cuando ntpd 4.2 cambió el significado de notrust. suspiro

6. Si no está brindando servicio de tiempo a otros, entonces probablemente no necesite toda la potencia de ntpd regular y debería considerarlo openntpd. Escrito por el equipo de OpenBSD, es una implementación mucho más mínima, que utiliza la separación de privilegios y un archivo de configuración mucho más simple. Supuestamente no proporcionará el tiempo altamente preciso que ntpd proporcionará, pero es lo suficientemente bueno para un servidor o estación de trabajo normal.

• Si ntpd no pudiera conectarse con el servidor remoto, no vería un desplazamiento para ese servidor.
• Si ntpq sería bloqueado por ntpd, vería un mensaje de error claro de ntpq.
• Si algún otro servicio estableciera también el tiempo (como las herramientas de vmware), vería un salto de compensación para el servidor (ejecute ntpq -p cada 70 segundos).

La reach 7salida en ntpq indicaba que dejaba que ntpd solo se ejecutara durante unos 4 minutos. 7 es 111 binario, lo que significa que el servidor ya fue alcanzado 3 veces. ntp llega cada 64 segundos ( pollvalor) y ya esperó 30 segundos ( whenvalor) desde el último contacto.

Lo offset -0.136indicado, que el sistema ya está sincronizado. Solo ntpd aún no ha marcado el servidor como fuente. Solo dale más tiempo y aparecerá una pequeña estrella.

Entonces, en realidad tu ntpd se estaba sincronizando. Pero ntpd generalmente no se sincroniza en un gran salto (como ntpdate), pero trata de ajustar el tiempo lentamente y asegura durante varios ciclos que el tiempo es estable.

PD: Soy consciente de que la pregunta es muy antigua. Pero el problema es atemporal. Y todas las otras respuestas son simplemente engañosas en mi humilde opinión. VMTPare incluso recomienda ntpd para mantener la hora sincronizada.

Encontré mi sistema apagado y pregunté por qué el reloj HW no se sincronizaba con el reloj del sistema en un apagado limpio. Parece que hay una configuración NTP en sysconfig que necesita edición para que eso suceda.

En /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Lo puse a yes. Por supuesto, primero verifique que tenga un servidor NTP sólido y que el reloj de su sistema sea confiable.

Sabía que era eso: mi sesgo era de 47 segundos y mi reloj HW también estaba apagado en 47 segundos. ¡Bingo! Mi primera pista fueron las fallas de Kerberos que se ven en los registros. Kerberos y muchos NAS simplemente no funcionarán si el sesgo del reloj es demasiado grande.

¡Que tengas un buen día!

si está ejecutando vhost en vmware, consulte el siguiente artículo ... debería ayudarlo http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

Eche un vistazo a esta referencia para ver si puede ayudarlo a solucionar su problema:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

es posible que desee publicar el contenido de su archivo ntpd.conf, la salida de los comandos de depuración como ntpq -p

¿Y verifica tu fecha / hora?

Y verifique esto también, ejecute ntpdate y startup ntpd, ¿está sincronizado el tiempo?

con los mejores deseos