En nuestro cuadro de producción, tengo un problema con ntpd. Estoy habilitando la función NTP para nuestra caja de producción y observo un problema.
Iniciamos el demonio ntpd en el proceso de inicialización de nuestra caja. Durante ese tiempo no hay conexión a Internet. A continuación se muestra mi pequeño ntp.confarchivo.
driftfile /etc/ntp.drift
logconfig =syncstatus
server pool.ntp.org iburst
Nuestra caja obtiene conectividad a Internet un poco tarde una vez que aparece la interfaz. Esa vez veo que ntpd no sincroniza el reloj. Cuando lo hago ntpq -c as, lo entiendo no association id's found. Esperé casi 30 minutos pero aún así recibíno association id's found
Tengo que reiniciar el ntpd. Después de reiniciarlo, ntpd sincroniza el reloj y todo funciona normalmente. Pero nuevamente, si reinicio mi caja, ocurre el mismo problema. Nuevamente tengo que reiniciar ntpd, una vez que aparece el cuadro y se puede acceder a Internet.
¿Alguien enfrentó un tipo de problema similar?
¿Debo retrasar el inicio de ntpd hasta que aparezca la interfaz de hora?
Actualizar
Hice un poco más de experimento y lo reemplacé server pool.ntp.org iburstcon pool pool.ntp.org ibursty con este cambio ntpd sincroniza el reloj automáticamente. No tuve que reiniciar el ntpd. Entonces aquí me surge otra pregunta.
¿Qué pasó cuando lo reemplacé servercon pool?
¿Debo usar siempre poolpalabras clave en lugar de server?
¿Cuándo debo usar pooly cuándo debo usar server?
Investigué un poco y descubrí que
pool is the same as server, except it resolves one name into several addresses and uses them all
si están haciendo lo mismo, entonces ¿por qué server pool.ntp.org iburstno funcionó para mí, pero pool pool.ntp.org iburstfuncionó?
Actualizar
Como se sugirió, lo he usado poolen lugar de serverpero aún así mi reloj no puede sincronizarse durante el arranque. Anteriormente no association id's foundvenía, pero después de usar el grupo se muestra la lista.
GW:/admin# ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
===================================================================== =========
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -np
remote refid st t when poll reach delay offset jitter
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 34173 8811 yes none none reject mobilize 1
GW:/admin# ntpq -c "rv 34173"
associd=34173 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
srcadr=0.0.0.0, srcport=0, srchost="time.google.com", dstadr=0.0.0.0,
dstport=0, leap=11, stratum=16, precision=-19, rootdelay=0.000,
rootdisp=0.000, refid=POOL, reftime=(no time), rec=(no time), reach=000,
unreach=0, hmode=3, pmode=0, hpoll=6, ppoll=10, headway=0,
flash=1400 peer_dist, peer_unreach, keyid=0, offset=+0.000, delay=0.000,
dispersion=16000.000, jitter=0.002,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Veo el estado del flash como 1400. ¿Cuál es el significado de 1400No pude encontrar el estado del flash 1400en la documentación ntp?
Actualizar
Empezó a funcionar. Lo reemplacé iburstcon minpoll 3 maxpoll 4y luego está funcionando al reiniciar. Usé piscina como esta pool pool.ntp.org minpoll 3 maxpoll 4. No estoy seguro de qué diferencia hizo este cambio.
También leí que deberíamos evitar el uso de minpoll y maxpoll.
Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.
De todos modos gracias a todos por ayudarme.
Respuesta1
Cuando proporciona un servidor a ntpd, al inicio resuelve el nombre de host en una dirección IP e intenta usar la dirección IP para sincronizar la hora. Si ese nombre de host no se resuelve, lo elimina. Incluso si lo resuelve, no recuerda el nombre del host, sólo la dirección IP.
Si el servidor en su serverlínea era un host local con una dirección IP fija (en lugar de un grupo dinámico), podría reemplazar el nombre del host con la dirección IP real y no debería eliminarlo incluso si la red no está activa en puesta en marcha.
Si, en cambio, proporciona un grupo a ntpd, conserva el nombre de host (y lo etiqueta con .POOL.). Periódicamente (incluso al inicio), resolverá ese nombre de host en DNS y agregará cualquier IP que obtenga como entradas separadas, y eliminará algunas de las menos favorables.
Puedes ver algo de esto con el comando ntpq -np o equivalententpq -n -c peers
Tenga en cuenta que también hay problemas de tiempo y de versión ntpd con todo esto. Este problema exacto se presentó como un error en ntpd y ha habido varias variaciones de solución. Algunas versiones de ntpd pospondrán la resolución del nombre de host si falla, pero es posible que eventualmente abandonen de todos modos; por lo que si estás probando desconectando brevemente la red y volviendo a conectarla, es posible que el problema no ocurra. Además, ntp utiliza un algoritmo de sondeo que aumenta exponencialmente el tiempo de sondeo del host tanto para hosts accesibles como inalcanzables (dependiendo de la estabilidad de su reloj y la utilidad del host como sincronización de tiempo) con un límite superior de 1024 segundos (32 minutos), por lo que si Si la accesibilidad de la red cambia, es posible que tarde ese tiempo en darse cuenta. (Los horarios e intervalos de la encuesta se enumeran en ntpq -np)
Además, algunos scripts de inicio de arranque utilizan ntpdate o herramientas similares para configurar el reloj del sistema en un servidor desde ntp.conf para que el reloj esté parcialmente sincronizado antes de que se inicie ntpd. Este es un intento único y, si falla, ntpd puede comenzar con el reloj muy equivocado. Si es solo un poco incorrecto, ntp lo solucionará, pero si es muy incorrecto, ntpd puede negarse a sincronizar el reloj y, en algunos casos y versiones de ntpd, puede fallar o cerrarse. Algunas versiones de ntpd tienen sus propias opciones de grandes pasos de reloj único.