366 votos

Alguien más tiene altas tasas de Linux server se bloquea durante un salto segundo día?

*NOTA: si su servidor tiene todavía problemas debido a confundirse kernels, y usted no puede reiniciar - la solución más sencilla que se propone con gnu fecha instalado en su sistema es: fecha: s ahora. Esto restablecerá el núcleo interno "time_was_set" variable y revisión de la CPU acaparando futex bucles en java y otras herramientas de espacio de usuario. He straced este comando en mi propio sistema confirmó que está haciendo lo que dice en la lata *

Post-MORTEM

Decepción: lo único que murió fue mi VPN (openvpn) enlace al clúster, por lo que hubo un excitante par de segundos mientras se re-establecido. Todo lo demás estaba bien, y a partir de ntp fue limpiamente después de que el segundo salto había pasado.

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

Si miras en el Marco del blog en http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - él tiene una solución para eliminar gradualmente el cambio de hora durante 24 horas utilizando ntpd-x para evitar el 1 de segunda saltar. Esta es una alternativa manchando método para el funcionamiento de su propio ntp infraestructura.


Justo hoy, Sat, 30 de junio, 2012 - comenzando poco después del inicio de la jornada GMT. Hemos tenido un puñado de servidores en diferentes centros de datos, mediante la gestión de los diferentes equipos que van todos oscuro - no responde a los pings, pantalla en blanco.

Todos están ejecutando Debian Squeeze - con todo de stock kernel personalizado 3.2.21 construye. La mayoría son de Dell M610 hojas, pero también he perdido una Dell R510 y otros departamentos han perdido máquinas de otros fabricantes también. Había también un viejo IBM x3550 que se estrelló y que pensé que podría estar relacionado, pero ahora me pregunto.

El accidente que me hizo llegar un volcado de pantalla desde dijo:

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

Por desgracia, las hojas de todos los que supuestamente había kdump configurado, pero murió tan duro que kdump no de gatillo y tenían la consola de supresión de encendido. Yo lo he desactivado la consola de supresión de ahora, así que crucemos los dedos voy a tener más información después de que el próximo choque.

Sólo quiero saber si es un hilo común o "nosotros". Es realmente extraño que son diferentes de las unidades en los diferentes centros de datos comprado en diferentes ocasiones y ejecutar por los diferentes administradores (I ejecutar el FastMail.FM)... y ahora incluso de diferentes proveedores de hardware. La mayoría de las máquinas que se estrelló había sido durante semanas/meses y se estaban ejecutando 3.1 o 3.2 de la serie de núcleos.

El más reciente accidente fue una máquina que sólo había sido hasta cerca de 6 horas de funcionamiento 3.2.21.

LA SOLUCIÓN

Ok gente, he aquí cómo he trabajado alrededor de ella.

  1. movilidad ntp: /etc/init.d/ntp stop
  2. creado http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (código de robo de Marco, ver entradas de blog en los comentarios)
  3. corrió fixtime.pl sin un argumento, al ver que no fue un salto segundo set
  4. corrió fixtime.pl con un argumento para quitar el segundo salto

NOTA: depende de la adjtimex. He puesto una copia de la exprimir adjtimex binario en http://linux.brong.fastmail.fm/2012-06-30/adjtimex - se ejecutará sin necesidad de dependencias en un squeeze de 64 bits del sistema. Si la pones en el mismo directorio como fixtime.pl, se utilizará si el sistema no está presente. Obviamente, si usted no tiene squeeze de 64 bits... encontrar su propio.

Yo voy a empezar a ntp de nuevo mañana.

Como un usuario anónimo sugirió - una alternativa a la ejecución adjtimex es sólo el tiempo, que presumiblemente también el leapsecond contador.

322voto

Buggieboy Puntos 1875

Esto es causado por un bloqueo activo cuando ntpd llamadas adjtimex(2) para decirle al kernel para insertar un segundo salto. Ver lkml la publicación de http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat también debe ser la actualización de su artículo de KB así. https://access.redhat.com/knowledge/articles/15145

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

La solución es desactivar ntpd. Si ntpd ya emitió el adjtimex(2) de la llamada, puede ser necesario desactivar el ntpd y reiniciar el sistema para ser 100% seguro.

Esto afecta a red hat enterprise linux 6 y otras distros ejecución de los núcleos nuevos (la más reciente de aprox 2.6.26), pero no RHEL 5.

La razón de esto es que ocurren antes de que el segundo salto es en realidad programada para ocurrir es que ntpd permite que el núcleo de manejar el salto de la segunda a la medianoche, pero debe alertar al kernel para insertar el salto de segundo antes de la medianoche. ntpd pide, por consiguiente, adjtimex(2) en algún momento durante el día del segundo salto, momento en el que este error se activa.

Si usted tiene adjtimex(8) instalado, puede utilizar esta secuencia de comandos para determinar si la bandera 16 se establece. Indicador 16 es "insertar salto de segunda":

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

ACTUALIZACIÓN:

Red Hat ha actualizado su artículo de KB a la nota: "RHEL 6 clientes pueden estar afectados por un problema conocido que causa el NMI de vigilancia para detectar un bloqueo al recibir la NTP leapsecond anuncio. Este problema está siendo abordado de una manera oportuna. Si sus sistemas de recibido el leapsecond anuncio y no experimentar este problema, entonces ya no serán afectados."

ACTUALIZACIÓN: La lengua fue retirado de la Red Hat artículo; y una segunda KB solución fue mayor detalle la adjtimex(2) crash en cuestión: https://access.redhat.com/knowledge/solutions/154713

Sin embargo, el cambio de código en la LKML post por IBM Ingeniero Juan Stultz notas también puede ser un interbloqueo cuando el segundo salto se aplica en realidad, si lo desea, puede desactivar el segundo salto reiniciando o el uso de adjtimex(8) después de la desactivación de ntpd.

ÚLTIMA ACTUALIZACIÓN:

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

Si estoy leyendo bien esta vez, yo estaba equivocado acerca de la existencia de otro interbloqueo cuando el segundo salto se aplica. Que parece ser que Red Hat opinión, basada en su KB entrada. Sin embargo, si usted ha desactivado ntpd, tenerlo desactivado por otros 10 minutos, de modo que usted no golpea el interbloqueo cuando ntpd llamadas adjtimex(2).

Vamos a averiguar si hay más errores de pronto :)

POST-SALTO SEGUNDA ACTUALIZACIÓN:

Pasé las últimas horas de lectura a través de la ntpd y pre-revisión (buggy) código del núcleo, y aunque puedo estar equivocado aquí, voy a intentar explicar lo que yo creo que estaba pasando:

En primer lugar, ntpd llamadas adjtimex(2) todo el tiempo. Esto se hace como parte de su "reloj de filtro de lazo", que se define en local_clock en ntp_loopfilter.c. Se puede ver que el código aquí: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (de ntp versión 4.2.6).

El reloj filtro de lazo se ejecuta muy a menudo -- se ejecuta cada vez que ntpd sondea sus servidores que precede, que por defecto es cada 17 minutos o más. El correspondiente bit del reloj filtro de lazo es:

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

Y luego:

ntp_adjtime(&ntv)

En otras palabras, en los días cuando hay un segundo salto, ntpd establece el "STA_INS" de la bandera y llamadas adjtimex(2) (a través de su portabilidad-wrapper).

Que el sistema de llamada hace su camino hacia el núcleo. Aquí está el correspondiente código del kernel: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

El núcleo codepath es aproximadamente esto:

  • línea 663 - inicio de la do_adjtimex rutina.
  • línea 691 - cancelar cualquier existentes salto-segundo temporizador.
  • línea 709 - agarrar el ntp_lock spinlock (este bloqueo está involucrado en el posible bloqueo activo de choque)
  • línea 724 - llamada process_adjtimex_modes.
  • línea 616 - llamada process_adj_status.
  • línea 590 - set time_status variable global, con base en los indicadores establecidos en adjtimex(2) llamada
  • línea 592 - verificación time_state variable global. en la mayoría de los casos, llame a ntp_start_leap_timer.
  • línea 554 - verificación time_status variable global. STA_INS se establezca, a fin de establecer time_state a TIME_INS y llame a hrtimer_start (otro núcleo de la función) para iniciar el segundo salto del temporizador. en el proceso de creación de un temporizador, este código se agarra a la xtime_lock. si esto sucede mientras otra CPU ya ha acaparado la xtime_lock y la ntp_lock, entonces el núcleo livelocks. esta es la razón por la que Juan Stultz escribió el parche para evitar el uso de hrtimers. Esto es lo que estaba causando todos los problemas de hoy.
  • línea 598 - si ntp_start_leap_timer no era en realidad el inicio de un salto temporizador, ajuste time_state a TIME_OK
  • línea 751 - suponiendo que el kernel no livelock, la pila se desenvuelve y la ntp_lock spinlock es liberado.

Hay un par de cosas interesantes aquí.

En primer lugar, la línea 691 cancela la existente temporizador cada vez que adjtimex(2) se llama. Entonces, 554 re-crea que el timer. Esto significa que cada vez ntpd corrió su reloj filtro de lazo, el código erróneo fue invocada.

Por lo tanto creo que Red Hat estaba equivocado cuando dijo que una vez que ntpd había establecido el salto-segundo indicador, el sistema no falla. Yo creo que cada sistema que ejecuta ntpd tenía el potencial de livelock cada 17 minutos (o más) para el período de 24 horas antes del salto-segundo. Creo que esto también puede explicar por qué muchos de los sistemas se estrelló; una sola oportunidad de estrellarse será mucho menos probable que golpear en comparación con el 3 posibilidades de una hora.

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

Segundo, esto explica por qué la carga de los sistemas tenían más probabilidades de accidente. Cargado sistemas de manejo más interrupciones, causando el "do_tick" núcleo de la función a llamar más a menudo, dando más de una oportunidad para que este código se ejecute y agarrar el ntp_lock mientras el temporizador está siendo creado.

Tercero, hay una posibilidad de que el sistema se bloquea cuando el salto-segundo ocurre realmente? Yo no lo sé, pero posiblemente sí, porque el temporizador que se activa y realmente ejecuta el salto-segundo ajuste (ntp_leap_second, en línea 388) también se agarra a la ntp_lock spinlock, y tiene una llamada a hrtimer_add_expires_ns. No sé si esa llamada también podría ser capaz de causar un bloqueo activo, pero no parece imposible.

Finalmente, lo que hace que el salto-la segunda bandera a ser deshabilitado después de que el salto-segundo ha de ejecutar? La respuesta no es ntpd deja de configuración de el salto-la segunda bandera en algún momento después de la medianoche, cuando llama a adjtimex(2). Desde que la bandera no está establecida, la verificación en línea 554 no será verdad, y no el temporizador va a ser creado, y de la línea de 598 restablecerá el time_state variable global para TIME_OK. Esto explica por qué si se activa la bandera con adjtimex(8) justo después de que el segundo salto, usted todavía podría ver el salto-la segunda bandera conjunto.

En definitiva, el mejor consejo para el día de hoy parece ser la primera que me dio después de todo: deshabilitar ntpd, y deshabilitar el salto-la segunda bandera.

Y algunos pensamientos finales:

  • ninguno de los vendedores de Linux notado Juan Stultz del parche y lo aplicó a sus núcleos :(
  • por qué no, John Stultz alerta de algunos de los proveedores de esto era necesario? tal vez la posibilidad de que el bloqueo activo parecía lo suficientemente baja haciendo ruido no estaba justificada.
  • He oído informes Java de los procesos de fijación de arriba o de girar cuando el salto segunda fue aplicado. Tal vez deberíamos seguir de Google plomo y repensar la forma en que se aplican salto-segundos para nuestros sistemas: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Actualización de Juan Stultz:

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

El post contiene un paso-por-paso pie-a través de ¿por qué el segundo salto causado la futex temporizadores a caducar antes de tiempo y de forma continua, aumentando la carga de la CPU.

33voto

HikeOnPast Puntos 504

Esto nos golpeó duro. Después de reiniciar muchos de nuestros anfitriones, el siguiente resultó ser vergonzosamente simple y plenamente eficaz sin un host de reiniciar:

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

Todo lo que se requiere para restablecer el reloj del sistema. Sheesh. Lo he dar a conocer este seis horas.

24voto

jon Puntos 785

Un sencillo programa en C que borra el segundo salto de bits en el núcleo del estado en tiempo de campo:

#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 ejecutar como root.

Es probable que usted desee dejar de ntpd antes de ejecutarlo y reiniciar ntpd después de que el segundo salto.

18voto

Gregor Puntos 181

Post mortem parece ./lsec no tiene un efecto.

Lo que estamos viendo es un montón de softirqd procesos de comer CPU (generalmente lineal, para la carga de procesos java)

Lo que hace el trabajo de revisión post-MORTEM con salto segundos ya aplicada por el ntp es la siguiente:

Parece ser suficiente para sólo cuestión:

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

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

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

17voto

Luca Filipozzi Puntos 314

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

Este hilo en comp.los protocolos.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 aún no ha sucedido: 23:59:60 UTC

Finalmente, https://access.redhat.com/knowledge/articles/15145 dice lo siguiente: "Cuando el segundo salto, el núcleo imprime un mensaje en el registro del sistema. Hay una posibilidad de que la impresión de este mensaje puede provocar que el núcleo se bloquea en Red Hat Enterprise Linux."

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: