Pregunta ¿Alguien más está experimentando altas tasas de fallas en el servidor Linux durante un segundo día?


* NOTA: si su servidor todavía tiene problemas debido a núcleos confusos, y no puede reiniciar, la solución más simple propuesta con gnu date instalada en su sistema es: date -s ahora. Esto restablecerá la variable interna "time_was_set" del kernel y reparará los lazos de futex de la CPU en java y otras herramientas del espacio de usuario. He marcado este comando en mi propio sistema y confirmé que está haciendo lo que dice en la lata *

POST MORTEM

Anticlimax: lo único que murió fue mi enlace VPN (openvpn) al clúster, por lo que hubo unos segundos emocionantes mientras se restablecía. Todo lo demás estaba bien, y la puesta en marcha de ntp fue limpiamente después de que había pasado el segundo.

He escrito mi experiencia completa del día en http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

Si miras el blog de Marco en http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - tiene una solución para eliminar el cambio de hora durante 24 horas usando ntpd -x para evitar el salto de 1 segundo. Este es un método alternativo para ejecutar su propia infraestructura ntp.


Hoy mismo, sábado 30 de junio de 2012, comenzando poco después del comienzo del día GMT. Hemos tenido un puñado de servidores en diferentes centros de datos administrados por diferentes equipos, todos se apagan, sin responder a pings, pantalla en blanco.

Todos están ejecutando Debian Squeeze, con todo, desde el kernel común hasta las compilaciones personalizadas 3.2.21. La mayoría son blades Dell M610, pero también acabo de perder un Dell R510 y otros departamentos también han perdido máquinas de otros proveedores. También había un IBM x3550 más antiguo que se estrelló y que pensé que podría no estar relacionado, pero ahora me pregunto.

El único accidente del que obtuve un volcado de pantalla dijo:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

Desafortunadamente, todos los blades supuestamente tenían kdump configurado, pero murieron tan duramente que kdump no se activó, y se activó el borrado de la consola. He desactivado el borrado de la consola ahora, por lo que los dedos se cruzaron. Tendré más información después del siguiente bloqueo.

Solo quiero saber si es un hilo común o "solo nosotros". Es realmente extraño que sean unidades diferentes en diferentes centros de datos comprados en diferentes momentos y ejecutados por diferentes administradores (yo ejecuto los FastMail.FM) ... y ahora incluso diferentes proveedores de hardware. La mayoría de las máquinas que se estrellaron habían estado funcionando durante semanas / meses y tenían núcleos de la serie 3.1 o 3.2.

El bloqueo más reciente fue una máquina que solo llevaba 6 horas funcionando 3.2.21.

El trabajo

Ok gente, así es como trabajé alrededor de esto.

  1. ntp deshabilitado: /etc/init.d/ntp stop
  2. creado http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (código robado de Marco, vea las publicaciones del blog en los comentarios)
  3. corrió fixtime.pl sin un argumento para ver que había un segundo conjunto salto
  4. corrió fixtime.pl con un argumento para eliminar el segundo salto

NOTA: depende de adjtimex. He puesto una copia del apretón adjtimex binario en http://linux.brong.fastmail.fm/2012-06-30/adjtimex - Se ejecutará sin dependencias en un sistema de compresión de 64 bits. Si lo pones en el mismo directorio que fixtime.pl, se utilizará si el sistema uno no está presente. Obviamente, si no tiene una compresión de 64 bits ... encuentre la suya propia.

Voy a comenzar ntp mañana otra vez.

Como sugirió un usuario anónimo, una alternativa a la ejecución adjtimex es solo configurar el tiempo usted mismo, lo que presumiblemente también borrará el contador de salto de segundo.


366
2018-06-30 16:15


origen


Hay un segundo salto hoy, el 30. Dudo en insinuar que ese es su problema, pero estaré observando de cerca mis máquinas Debian. - jscott
Desde la mañana, hemos perdido al menos 9 cajas de compresión de Debian diferentes de varios proveedores, todos con un stock en ejecución 2.6.32 kernel. tampoco hemos podido obtener un volcado de memoria debido a la supresión de la consola ... - kargig
lkml publicando sobre esto lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
Gracias por reportar esto! Ahora estoy mirando mis servidores muy, muy de cerca. - Janne Pikkarainen
El hilo de LKML indicó que date -s "`date`" Ayuda - ciertamente me ayudó. - Pointy


Respuestas:


Esto se debe a un bloqueo vital cuando ntpd llama a adjtimex (2) para decirle al núcleo que inserte un segundo de salto. Ver publicación lkml http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat también debería estar actualizando su artículo de KB también. https://access.redhat.com/knowledge/articles/15145

ACTUALIZACIÓN: Red Hat tiene un segundo artículo de KB solo para este problema aquí: https://access.redhat.com/knowledge/solutions/154713 - el artículo anterior es para un problema anterior, no relacionado

La solución es simplemente apagar ntpd. Si ntpd ya emitió la llamada adjtimex (2), es posible que deba desactivar ntpd y reiniciar para estar 100% seguro.

Esto afecta a RHEL 6 y otras distribuciones que ejecutan kernels más nuevos (más nuevos que aproximadamente 2.6.26), pero no a RHEL 5.

La razón por la que esto está ocurriendo antes de el segundo salto que está programado para ocurrir es que ntpd permite que el kernel maneje el segundo en la medianoche, pero debe alertar al núcleo para que inserte el segundo antes de la medianoche. ntpd, por lo tanto, llama adjtimex (2) en algún momento durante el día del segundo salto, momento en el que se activa este error.

Si tiene adjtimex (8) instalado, puede usar este script para determinar si el indicador 16 está establecido. La bandera 16 es "insertando el segundo salto":

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'

ACTUALIZAR:

Red Hat ha actualizado su artículo de KB para tener en cuenta: "Los clientes de RHEL 6 pueden verse afectados por un problema conocido que causa que NMI Watchdog detecte un bloqueo al recibir el anuncio de un salto de segundo NTP. Este problema se está solucionando de manera oportuna. Si sus sistemas lo recibieron El anuncio de un salto de segundo y no experimentó este problema, entonces ya no se ven afectados ".

ACTUALIZACIÓN: el lenguaje anterior se eliminó del artículo de Red Hat; y se agregó una segunda solución de KB que detalla el problema del fallo adjtimex (2): https://access.redhat.com/knowledge/solutions/154713

Sin embargo, el cambio de código en la publicación LKML por el ingeniero de IBM John Stultz señala que también puede haber un interbloqueo cuando el segundo salto se aplica realmente, por lo que es posible que desee desactivar el segundo salto reiniciando o utilizando adjtimex (8) después de desactivar ntpd.

ACTUALIZACIÓN FINAL:

Bueno, no soy un dev del núcleo, pero revisé el parche de John Stultz de nuevo aquí: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Si lo leo bien esta vez, me equivoqué al tener otro punto muerto cuando se aplica el salto de segundo. Esa parece ser también la opinión de Red Hat, basada en su entrada de KB. Sin embargo, si ha deshabilitado ntpd, manténgalo deshabilitado durante otros 10 minutos, para que no salga del punto muerto cuando ntpd llame a adjtimex (2).

Descubriremos si hay más errores pronto :)

SEGUNDA ACTUALIZACIÓN POST-LEAP:

Pasé las últimas horas leyendo el código del kernel ntpd y pre-patch (buggy), y aunque puedo estar muy equivocado aquí, intentaré explicar lo que creo que estaba pasando:

Primero, ntpd llama adjtimex (2) todo el tiempo. Lo hace como parte de su "filtro de bucle de reloj", definido en local_clock en ntp_loopfilter.c. Puedes ver ese código aquí: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (De la versión ntp 4.2.6).

El filtro de bucle de reloj se ejecuta con bastante frecuencia: se ejecuta cada vez que ntpd sondea sus servidores ascendentes, que de forma predeterminada es cada 17 minutos o más. El bit relevante del filtro de bucle de reloj es:

if (sys_leap == LEAP_ADDSECOND)
    ntv.status |= STA_INS;

Y entonces:

ntp_adjtime(&ntv)

En otras palabras, en los días en que hay un segundo de salto, ntpd establece el indicador "STA_INS" y llama a adjtimex (2) (a través de su envoltorio de portabilidad).

Esa llamada al sistema se abre paso hacia el kernel. Aquí está el código del núcleo relevante: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

La ruta de código del kernel es aproximadamente esto:

  • línea 663 - inicio de la rutina do_adjtimex.
  • línea 691 - cancela cualquier temporizador de segundo salto existente.
  • línea 709 - agarre el ntp_lock spinlock (este bloqueo está involucrado en el posible bloqueo de Livelock)
  • línea 724 - llamada process_adjtimex_modes.
  • línea 616 - llamada process_adj_status.
  • línea 590 - establece la variable global time_status, basada en los indicadores establecidos en la llamada adjtimex (2)
  • línea 592 - verifique la variable global time_state. en la mayoría de los casos, llame a ntp_start_leap_timer.
  • línea 554 - verifique la variable global time_status. STA_INS se configurará, así que establezca time_state en TIME_INS y llame a hrtimer_start (otra función del kernel) para iniciar el temporizador de segundo salto. en el proceso de crear un temporizador, este código toma xtime_lock. si esto sucede mientras otra CPU ya ha agarrado el xtime_lock y El ntp_lock, luego el kernel livelocks. esta es la razón por la que John Stultz escribió el parche para evitar el uso de hrtimers. Esto es lo que estaba causando problemas a todos hoy.
  • línea 598: si ntp_start_leap_timer no inició realmente un temporizador de salto, establezca time_state en TIME_OK
  • línea 751 - asumiendo que el kernel no está activo, la pila se desenrolla y el ntp_lock spinlock se libera.

Hay un par de cosas interesantes aquí.

Primero, la línea 691 cancela el temporizador existente cada vez que se llama adjtimex (2). Entonces, 554 recrea ese temporizador. Esto significa que cada vez que ntpd ejecutaba su filtro de bucle de reloj, se invocaba el código con errores.

Por lo tanto, creo que Red Hat se equivocó cuando dijeron que una vez que ntpd había establecido el indicador de salto de segundo, el sistema no se bloqueaba. Creo que cada sistema que ejecuta ntpd tiene el potencial de bloquearse cada 17 minutos (o más) durante el período de 24 horas antes del segundo. Creo que esto también puede explicar por qué tantos sistemas fallaron; una probabilidad única de estrellarse sería mucho menos probable en comparación con 3 oportunidades por hora.

ACTUALIZACIÓN: En la solución de KB de Red Hat en https://access.redhat.com/knowledge/solutions/154713 , Los ingenieros de Red Hat llegaron a la misma conclusión (que ejecutar ntpd continuamente afectaría el código del buggy). Y efectivamente lo hicieron varias horas antes que yo. Esta solución no estaba vinculada al artículo principal en https://access.redhat.com/knowledge/articles/15145 , así que no me di cuenta hasta ahora.

En segundo lugar, esto explica por qué los sistemas cargados eran más propensos a fallar. Los sistemas cargados manejarán más interrupciones, lo que hará que la función del kernel "do_tick" se llame más a menudo, lo que dará más posibilidades de que este código se ejecute y tome el ntp_lock mientras se creaba el temporizador.

En tercer lugar, ¿existe la posibilidad de que el sistema falle cuando realmente se produce el salto en segundo? No lo sé a ciencia cierta, pero posiblemente sí, porque el temporizador que se activa y en realidad ejecuta el ajuste de salto de segundo (ntp_leap_second, en la línea 388) también agarra el spinlock ntp_lock y tiene una llamada a hrtimer_add_expires_ns. No sé si esa llamada también podría causar un bloqueo vital, pero no parece imposible.

Finalmente, ¿qué hace que el indicador de salto de segundo se desactive después de que se haya ejecutado el salto de segundo? La respuesta es que ntpd deja de configurar el indicador de un segundo en algún momento después de la medianoche cuando llama adjtimex (2). Como la bandera no está activada, la verificación en la línea 554 no será verdadera, y no se creará ningún temporizador, y la línea 598 restablecerá la variable global time_state a TIME_OK. Esto explica por qué si marcó la bandera con adjtimex (8) justo después del segundo del salto, todavía vería el conjunto de la bandera del segundo del salto.

En resumen, el mejor consejo para hoy parece ser el primero que di después de todo: deshabilitar ntpd y deshabilitar el indicador de segundo salto.

Y algunos pensamientos finales:

  • ninguno de los proveedores de Linux notó el parche de John Stultz y lo aplicó a sus núcleos :(
  • ¿Por qué John Stultz no alertó a algunos de los proveedores de que esto era necesario? tal vez la posibilidad de que el livelock pareciera lo suficientemente bajo como para hacer ruido no estaba justificado.
  • He escuchado informes de procesos de Java bloqueando o girando cuando se aplicó el salto de segundo. Tal vez deberíamos seguir el ejemplo de Google y repensar cómo aplicamos saltos de segundo a nuestros sistemas: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Actualización de John Stultz:

https://lkml.org/lkml/2012/7/1/203

La publicación contenía un recorrido paso a paso de por qué el segundo salto provocó que los temporizadores futex expiraran de manera prematura y continua, aumentando la carga de la CPU.


322
2018-06-30 19:56



Gracias por la excelente respuesta. Así que el resto de nuestros servidores están esperando a fallar. Encantador. ¡El rodar se reinicia aquí venimos! - Bron Gondwana
¿Cómo puedo saber si el adjtimex ha sido emitido, ¿el kernel imprime algo en dmesg? ¿Qué posibilidades hay de que un sistema que no fallara antes de apagar ntpd se bloquee? - Hubert Kario
Hubert: ejecute "adjtimex" (normalmente se empaqueta por separado) y busque el indicador 16 para indicar un segundo de salto pendiente. - Dominic Cleal
Vas a odiar la tapa del representante. - Wesley
@WesleyDavid: No se preocupe, el límite de representantes se restablecerá a la medianoche UTC. Tal vez. - mmyers


Esto nos golpeó duro. Después de reiniciar muchos de nuestros hosts, lo siguiente resultó ser vergonzosamente simple y completamente efectivo sin un reinicio de host:

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

Todo lo que se requiere es reiniciar el reloj del sistema. Sheesh Lo que he dado por haber sabido esto hace seis horas.


33
2017-07-01 07:49



date -s "`date`" trabajó para mi. - Pointy
@DeanB: Publiqué a las 3 am UTC que restablecer el reloj funciona, desafortunadamente, tardó un tiempo en moderarse. Empezamos reiniciando servidores también - Gregor


Un programa simple en C que borra el bit de segundo salto en el campo de estado de tiempo del kernel:

#include <sys/timex.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv) {
    struct timex txc;
    int ret;

    (void) argc;
    (void) argv;

    bzero(&txc, sizeof(txc));
    txc.modes = 0;  /* fetch */
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (get)");
        return 1;
    }

    txc.modes = ADJ_STATUS;
    txc.status &= ~16;
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (set)");
        return 1;
    }

    return 0;
}

Guardar como lsec.c, compilar con gcc -Wall -Wextra -o lsec lsec.c y correr como root.

Es probable que desee detener ntpd antes de ejecutarlo y reiniciar ntpd después del segundo.


24
2018-06-30 23:13



Que hace (void) argc; ¿realizar? ¿Silencio la advertencia para la variable no utilizada? No usaría int main() lograr lo mismo? No intento ser un pedante, soy genuinamente curioso. - gparent


Postmortem parece ./lsec no tiene efecto.

Lo que estamos viendo es un montón de procesos de software que consumen CPU (generalmente lineales a la carga de procesos Java)

Lo que funciona para corregir POSTMORTEM con segundos de salto ya aplicados por ntp es lo siguiente:

Parece ser suficiente para simplemente emitir:

export LANG="en_EN"; date -s "`date`"

Esto debería reducir la carga sin reiniciar ntpd o reiniciar. Alternativamente puede emitir:

apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start

18
2017-07-01 03:41



por qué sntp -s y no ntpdate? - errordeveloper
ntpdate es solo una envoltura para sntp aquí, seguro que también está bien usar ntpdate. - Gregor
Ah, me perdí por completo que hay un paquete ntpdate para apretar donde en realidad es un binario. He editado mi publicación para incluir esto. - Gregor
También he escuchado informes similares sobre cómo solucionar este problema (como el uso de date -s). Parece que la solución solo requiere configurar la hora del sistema en lugar de desplazarla (el comportamiento predeterminado de ntpd cuando el desplazamiento es pequeño). Supongo que establecer el tiempo hace que los mecanismos internos de mantenimiento del tiempo del núcleo se reinicien. - Patrick
El uso de la CPU de mi aplicación Java también se disparó (con una gran cantidad de tiempo de CPU empleado en softirqd), esto lo solucionó. - Hubert Kario


http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back parece indicar que el kernel exprimidor de Debian no manejará el segundo salto.

Este hilo en comp.protocols.tim.ntp es de interés, también: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Dicho esto, el segundo salto todavía no ha sucedido: 23:59:60 UTC

Finalmente, https://access.redhat.com/knowledge/articles/15145 tiene lo siguiente que decir: "Cuando se produce el segundo salto, el kernel imprime un mensaje en el registro del sistema. Existe la posibilidad de que la impresión de este mensaje pueda causar que el kernel se bloquee en Red Hat Enterprise Linux".


17
2018-06-30 18:47



Pero el kernel 3.2.21 debería, presumiblemente, que es lo que al menos una de las máquinas se estaba ejecutando - Bron Gondwana
En algunas de esas máquinas que Bron indicó indicaron que en realidad hemos implementado una solución que debería manejar correctamente el próximo salto en segundo. - cosimo
¿Puede publicar la solución en algún lugar para que otros puedan revisar / sugerir ideas / probar? - kargig
No tengo una solución ... Solo estoy recopilando información. Tal vez debería haber puesto esto como un comentario en contra de la pregunta original. - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/… Contiene más detalles sobre cómo arreglarlo. - Bron Gondwana