Alguma outra pessoa que esteja enfrentando altas taxas de falhas no servidor Linux durante um segundo dia bissexto?

366

* OBSERVAÇÃO: se o seu servidor ainda tiver problemas devido a kernels confusos e você não puder reinicializar - a solução mais simples proposta com o gnu date instalado no seu sistema é: date -s now. Isso irá redefinir a variável interna "time_was_set" do kernel e consertar os laços de futex do CPU em java e outras ferramentas de espaço do usuário. Eu coloquei esse comando no meu próprio sistema e confirmei que ele está fazendo o que diz na lata *

POSTMORTEM

Anticlimax: a única coisa que morreu foi o meu link VPN (openvpn) para o cluster, então houve alguns instantes excitantes enquanto ele foi restabelecido. Tudo estava bem, e o start-up ntp foi limpo depois que o segundo bissexto passou.

Eu escrevi minha experiência completa do dia no link

Se você olhar para o blog de Marco em link - ele tem uma solução para alterar a mudança de horário durante 24 horas usando ntpd -x para evitar o salto de 1 segundo. Este é um método de espalhamento alternativo para executar sua própria infraestrutura ntp.

Apenas hoje, Sáb 30 de junho de 2012 - começando logo após o início do dia GMT. Nós tivemos um punhado de servidores em datacenters diferentes, como gerenciados por equipes diferentes, tudo escuro - não respondendo a pings, tela em branco.

Eles estão todos executando o Debian Squeeze - com tudo, desde o kernel padrão até o 3.2.21 customizado. A maioria é de blades Dell M610, mas também perdi um Dell R510 e outros departamentos também perderam máquinas de outros fornecedores. Houve também um antigo IBM x3550 que travou e que eu pensei que poderia estar relacionado, mas agora eu estou querendo saber.

O único acidente que eu fiz um dump de tela de disse:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0
Infelizmente todos os blades supostamente tinham o kdump configurado, mas eles morreram com tanta força que o kdump não disparou - e eles tinham o blanking do console ligado. Eu desativei a supressão do console agora, então dedos cruzados teremos mais informações após o próximo acidente.

Só quero saber se é um assunto comum ou "apenas nós". É realmente estranho que sejam unidades diferentes em datacenters diferentes comprados em momentos diferentes e executados por administradores diferentes (eu executo os do FastMail.FM) ... e agora até hardware de fornecedor diferente. A maioria das máquinas que travaram ficou em funcionamento por semanas / meses e estavam executando os núcleos da série 3.1 ou 3.2.

O crash mais recente foi uma máquina que tinha apenas cerca de 6 horas rodando 3.2.21.

O WORKAROUND

Ok pessoal, aqui está como eu trabalhei com isso.

  1. desativado ntp: /etc/init.d/ntp stop
  2. criou o link (código roubado do Marco, veja as postagens do blog nos comentários)
  3. executou fixtime.pl sem um argumento para ver que havia um segundo de pulsos
  4. executou fixtime.pl com um argumento para remover o segundo bissexto

NOTA: depende de adjtimex . Eu coloquei uma cópia do squeeze adjtimex binary no link - ele será executado sem dependências em um sistema squeeze de 64 bits. Se você colocá-lo no mesmo diretório que fixtime.pl , ele será usado se o sistema não estiver presente. Obviamente, se você não tiver squeeze de 64 bits ... encontre o seu próprio.

Vou começar ntp novamente amanhã.

Como um usuário anônimo sugeriu - uma alternativa para executar adjtimex é apenas definir a hora você mesmo, o que presumivelmente também limpará o contador de segundo plano.

    
por Bron Gondwana 30.06.2012 / 18:15

0 respostas