Alguém mais experimentando altas taxas de falhas no servidor Linux durante um segundo dia bissexto?

Isso é causado por um livelock quando o ntpd chama o adjtimex(2) para dizer ao kernel para inserir um segundo bissexto. Veja a postagem do lkml http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

A Red Hat também deve atualizar seu artigo da base de conhecimento. https://access.redhat.com/knowledge/articles/15145

ATUALIZAÇÃO: Red Hat tem um segundo artigo KB apenas para este problema aqui: https://access.redhat.com/knowledge/solutions/154713 - o artigo anterior é para um problema anterior não relacionado

A solução alternativa é apenas desligar o ntpd. Se o ntpd já emitiu a chamada adjtimex(2), pode ser necessário desabilitar o ntpd e reiniciar para ficar 100% seguro.

Isso afeta o RHEL 6 e outras distribuições que executam kernels mais recentes (mais recentes que aproximadamente 2.6.26), mas não o RHEL 5.

A razão pela qual isso está ocorrendo antes que o segundo bissexto esteja realmente programado para ocorrer é que o ntpd permite que o kernel lide com o segundo bissexto à meia-noite, mas precisa alertar o kernel para inserir o segundo bissexto antes da meia-noite. O ntpd, portanto, chama adjtimex(2) em algum momento durante o dia do segundo bissexto, momento em que esse bug é acionado.

Se você tiver o adjtimex(8) instalado, poderá usar este script para determinar se o sinalizador 16 está definido. O sinalizador 16 está "inserindo segundo bissexto":

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

ATUALIZAR:

A Red Hat atualizou seu artigo da base de conhecimento para observar: "Os clientes do RHEL 6 podem ser afetados por um problema conhecido que faz com que o NMI Watchdog detecte um travamento ao receber o anúncio de segundo bissexto do NTP. Este problema está sendo resolvido em tempo hábil. Se seus sistemas receberam o anúncio do segundo bissexto e não tiveram esse problema, eles não serão mais afetados."

ATUALIZAÇÃO: O idioma acima foi removido do artigo da Red Hat; e uma segunda solução KB foi adicionada detalhando o problema de falha do adjtimex(2): https://access.redhat.com/knowledge/solutions/154713

No entanto, a alteração de código na postagem LKML pelo engenheiro da IBM John Stultz observa que também pode haver um impasse quando o segundo bissexto é realmente aplicado, então você pode querer desabilitar o segundo bissexto reinicializando ou usando adjtimex(8) após desabilitar o ntpd.

ATUALIZAÇÃO FINAL:

Bem, eu não sou nenhum desenvolvedor do kernel, mas revisei o patch de John Stultz novamente aqui: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h =6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Se eu estou lendo certo desta vez, eu estava errado sobre haver outro impasse quando o segundo bissexto é aplicado. Essa também parece ser a opinião da Red Hat, com base em sua entrada na KB. No entanto, se você desativou o ntpd, mantenha-o desativado por mais 10 minutos, para que você não atinja o impasse quando o ntpd chamar o adjtimex(2).

Vamos descobrir se há mais bugs em breve :)

SEGUNDA ATUALIZAÇÃO PÓS-SALTO:

Passei as últimas horas lendo o código do kernel ntpd e pré-patch (com bugs) e, embora possa estar muito errado aqui, tentarei explicar o que acho que estava acontecendo:

Primeiro, o ntpd chama adjtimex(2) o tempo todo. Ele faz isso como parte de seu "filtro de loop de relógio", definido em local_clock em ntp_loopfilter.c. Você pode ver esse código aqui: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (do ntp versão 4.2.6).

O filtro de loop de relógio é executado com bastante frequência - ele é executado toda vez que o ntpd pesquisa seus servidores upstream, que por padrão é a cada 17 minutos ou mais. O bit relevante do filtro de loop de clock é:

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

E depois:

ntp_adjtime(&ntv)

Em outras palavras, nos dias em que há um segundo bissexto, o ntpd define o sinalizador "STA_INS" e chama adjtimex(2) (através de seu wrapper de portabilidade).

Essa chamada de sistema chega ao kernel. Aqui está o código do kernel relevante: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

O caminho de código do kernel é aproximadamente este:

• linha 663 - início da rotina do_adjtimex.
• linha 691 - cancela qualquer temporizador de segundo bissexto existente.
• linha 709 - pegue o spinlock ntp_lock (este bloqueio está envolvido no possível travamento do livelock)
• linha 724 - chame process_adjtimex_modes.
• linha 616 - chame process_adj_status.
• linha 590 - define a variável global time_status, com base nos sinalizadores definidos na chamada adjtimex(2)
• linha 592 - verifique a variável global time_state. na maioria dos casos, chame ntp_start_leap_timer.
• linha 554 - verifique a variável global time_status. STA_INS será definido, portanto, defina time_state como TIME_INS e chame hrtimer_start (outra função do kernel) para iniciar o cronômetro do segundo bissexto. no processo de criação de um timer, esse código pega o xtime_lock. se isso acontecer enquanto outra CPU já pegou o xtime_lock e o ntp_lock, então o kernel livelocks. é por isso que John Stultz escreveu o patch para evitar o uso de hrtimers. Isso é o que estava causando problemas a todos hoje.
• linha 598 - se ntp_start_leap_timer não iniciou um temporizador de salto, defina time_state como TIME_OK
• linha 751 - assumindo que o kernel não faz livelock, a pilha é desenrolada e o spinlock ntp_lock é liberado.

Há algumas coisas interessantes aqui.

Primeiro, a linha 691 cancela o cronômetro existente toda vez que adjtimex(2) é chamado. Em seguida, 554 recria esse temporizador. Isso significa que cada vez que o ntpd executou seu filtro de loop de clock, o código com bugs foi invocado.

Portanto, acredito que a Red Hat estava errada quando disse que uma vez que o ntpd tivesse definido o sinalizador de segundo bissexto, o sistema não travaria. Acredito que cada sistema executando o ntpd tinha o potencial de travar a cada 17 minutos (ou mais) pelo período de 24 horas antes do segundo bissexto. Acredito que isso também possa explicar por que tantos sistemas travaram; uma chance única de bater seria muito menos provável de acertar em comparação com 3 chances por hora.

ATUALIZAÇÃO: Na solução KB da Red Hat em https://access.redhat.com/knowledge/solutions/154713 , os engenheiros da Red Hat chegaram à mesma conclusão (que a execução do ntpd atingiria continuamente o código com erros). E, de fato, eles fizeram isso várias horas antes de mim. Esta solução não estava vinculada ao artigo principal em https://access.redhat.com/knowledge/articles/15145 , então não percebi até agora.

Em segundo lugar, isso explica por que os sistemas carregados eram mais propensos a travar. Sistemas carregados lidarão com mais interrupções, fazendo com que a função do kernel "do_tick" seja chamada com mais frequência, dando mais chance para esse código ser executado e pegar o ntp_lock enquanto o temporizador estava sendo criado.

Terceiro, há uma chance de o sistema travar quando o segundo bissexto realmente ocorrer? Eu não sei ao certo, mas possivelmente sim, porque o temporizador que dispara e realmente executa o ajuste do segundo bissexto (ntp_leap_second, na linha 388) também pega o spinlock ntp_lock e tem uma chamada para hrtimer_add_expires_ns. Não sei se essa chamada também pode causar um livelock, mas não parece impossível.

Finalmente, o que faz com que o sinalizador de segundo bissexto seja desabilitado após a execução do segundo bissexto? A resposta é que o ntpd para de definir o sinalizador de segundo bissexto em algum ponto após a meia-noite quando chama adjtimex(2). Como o sinalizador não está definido, a verificação na linha 554 não será verdadeira e nenhum temporizador será criado, e a linha 598 redefinirá a variável global time_state para TIME_OK. Isso explica por que se você verificar o sinalizador com adjtimex(8) logo após o segundo bissexto, você ainda verá o sinalizador de segundo bissexto definido.

Resumindo, o melhor conselho para hoje parece ser o primeiro que dei afinal: desabilite o ntpd e desabilite o sinalizador de segundo bissexto.

E algumas considerações finais:

• nenhum dos fornecedores de Linux notou o patch de John Stultz e o aplicou em seus kernels :(
• por que John Stultz não alertou alguns dos fornecedores de que isso era necessário? talvez a chance de o livelock parecer baixa o suficiente para fazer barulho não fosse justificado.
• Ouvi relatos de processos Java travando ou girando quando o segundo bissexto foi aplicado. Talvez devêssemos seguir o exemplo do Google e repensar como aplicamos os segundos bissextos aos nossos sistemas: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

Atualização de 02/06 de John Stultz:

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

A postagem continha um passo a passo de por que o segundo bissexto fazia com que os cronômetros futex expirassem prematuramente e continuamente, aumentando a carga da CPU.

Isso nos atingiu em cheio. Depois de reiniciar muitos de nossos hosts, o seguinte acabou sendo embaraçosamente simples e totalmente eficaz sem a reinicialização do host:

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

Tudo o que é necessário é redefinir o relógio do sistema. Sheesh. O que eu dei para saber disso seis horas atrás.

Um programa em C simples que limpa o segundo bit bissexto no campo de status de tempo do 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;
}

Salve como lsec.c, compile com gcc -Wall -Wextra -o lsec lsec.ce execute como root.

Você provavelmente desejará parar o ntpd antes de executá-lo e reiniciar o ntpd após o segundo bissexto.

Postmortem parece que ./lsec não tem efeito.

O que estamos vendo são muitos processos softirqd consumindo CPU (geralmente lineares à carga de processos Java)

O que funciona para corrigir POSTMORTEM com segundos bissextos já aplicados pelo ntp é o seguinte:

Parece ser suficiente apenas emitir:

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

Isso deve reduzir a carga sem reiniciar ou reinicializar o ntpd. Alternativamente, você pode emitir:

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

http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back parece indicar que o kernel squeeze do Debian não vai lidar com o segundo bissexto.

Este tópico em comp.protocols.tim.ntp também é interessante: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Dito isto, o segundo bissexto ainda não aconteceu: 23:59:60 UTC

Finalmente, https://access.redhat.com/knowledge/articles/15145 tem o seguinte a dizer: "Quando ocorre o segundo bissexto, o kernel imprime uma mensagem no log do sistema. Há uma chance de que a impressão desta mensagem pode fazer com que o kernel falhe no Red Hat Enterprise Linux."