Causas probables de muerte inesperada de NTPD y soluciones

9

En una aplicación web que usa s3 para el almacenamiento de documentos físicos, estamos experimentando problemas con la muerte continua de NTP. Esto parece suceder aproximadamente una o dos veces al día. Cuando se produce esto, se proporciona muy poca información, aparte de que el archivo PID existe pero el servicio está inactivo cuando verifico el estado.

¿Alguien puede sugerir causas probables de muerte por NTPD? Supongo que tal vez la deriva del reloj está causando que muera, pero tampoco estoy seguro de qué causaría eso. Hay más que suficiente memoria y espacio en disco disponible.

La última vez que murió el servicio, este fue el resultado:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

— usuario275940
fuente

¿Qué sistema operativo y versión? ¿Hay un ocultamiento corriendo? ¿Cuántos servidores ntp están configurados? ¿Qué opciones de ntpd son activas?

— Nils

Puede intentar eliminar su archivo ntp.drift, su valor puede ser demasiado alto y causar sesgo

— Rqomey

6

Yo diría que no hay un método de 1 minuto para encontrar la razón exacta.

Tuvimos problemas similares antes en nuestro entorno ESXi. Para abreviar la historia, descubrimos que el reloj del host ESXi se movía mucho y que las máquinas virtuales invitadas sincronizaban la hora del host ESXi y del servidor NTP ascendente. Esto causó confusión en NTPd en máquinas virtuales, por lo tanto, murió con bastante frecuencia.

También encontramos en algunos casos raros que la pérdida aleatoria de paquetes también provocó el abandono de NTPd porque el tiempo de ida y vuelta entre su servidor y el servidor NTPd aguas arriba se utiliza para calcular el tiempo de deriva.

En los dos casos anteriores, si NTPd ve una deriva de tiempo masiva, por ejemplo, más de 1000, se cierra por defecto. -g opción ayudará un poco.

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

Puede echar un vistazo al registro del sistema , que debe tener algunas palabras que pueden darle una pista. También puede supervisar la salida "ntpq -p" para tener una idea aproximada de cómo se desarrolla el desplazamiento.

— Enzo Wang
fuente

Cuando ejecuta ntpd en máquinas virtuales, no debe sincronizar la hora con el host y no debe incluir el reloj local como referencia.

— Paul Gear

3

El mensaje de registro indica claramente que la deriva del reloj es el motivo de la salida. Soluciones posibles:

Inicie ntpd con la bandera -g; sin embargo, esto no solucionará la causa raíz, que es la inclinación del reloj.
Ejecute ntpdate antes de iniciar ntpd; probablemente la misma advertencia.

Agregue más fuentes de tiempo; NTP necesita de 4 a 6 fuentes para mantener una buena precisión. Una manera simple de hacer esto es incluir referencias repetidas a [0-3] .YOURREGION.pool.ntp.org en su configuración, por ej.

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

— Paul Gear
fuente

1

Otra opción que puedes probar es crony. En nuestras pruebas, funciona de manera más estable que ntpd y maneja mejor el sesgo de tiempo experimentado en entornos virtuales.

http://chrony.tuxfamily.org/

— Jokajak
fuente