* 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.
/etc/init.d/ntp stop
fixtime.pl
sem um argumento para ver que havia um segundo de pulsos 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.