*NOTA: 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 em seu sistema é: date -s now. Isso redefinirá a variável interna "time_was_set" do kernel e corrigirá os loops futex da CPU em java e outras ferramentas de espaço do usuário. Eu tracei este comando no meu próprio sistema e confirmei que ele está fazendo o que diz na lata *
PÓS-MORTEM
Anticlímax: a única coisa que morreu foi meu link VPN (openvpn) para o cluster, então houve alguns segundos emocionantes enquanto ele era restabelecido. Tudo o resto estava bem, e a inicialização do ntp foi limpa após o segundo bissexto ter passado.
Eu escrevi minha experiência completa do dia em http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/
Se você olhar para o blog de Marco em http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - ele tem uma solução para faseando a mudança de horário em 24 horas usando ntpd -x para evitar o salto de 1 segundo. Este é um método de mancha alternativo para executar sua própria infraestrutura ntp.
Apenas hoje, sábado 30 de junho de 2012 - começando logo após o início do dia GMT. Tivemos um punhado de servidores em diferentes datacenters, gerenciados por equipes diferentes, todos apagados - sem responder a pings, tela em branco.
Eles estão todos rodando o Debian Squeeze - com tudo, desde kernel padrão até builds 3.2.21 customizados. A maioria são blades Dell M610, mas também acabei de perder um Dell R510 e outros departamentos também perderam máquinas de outros fornecedores. Houve também um IBM x3550 mais antigo que travou e que eu pensei que poderia não estar relacionado, mas agora estou me perguntando.
A única falha da qual recebi um despejo de tela 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 morreram com tanta força que o kdump não foi acionado - e eles tinham o apagamento do console ativado. Eu desativei o apagamento do console agora, então dedos cruzados terei mais informações após a próxima falha.
Só quero saber se é um fio comum ou "só nós". É realmente estranho que sejam unidades diferentes em datacenters diferentes, compradas em momentos diferentes e administradas por administradores diferentes (eu corro os FastMail.FM)... e agora até hardware de fornecedores diferentes. A maioria das máquinas que travaram estavam funcionando por semanas/meses e estavam rodando kernels da série 3.1 ou 3.2.
A falha mais recente foi uma máquina que estava funcionando apenas cerca de 6 horas executando o 3.2.21.
A SOLUÇÃO
Ok pessoal, aqui está como eu trabalhei em torno disso.
- ntp desativado:
/etc/init.d/ntp stop - criado http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (código roubado de Marco, veja as postagens do blog nos comentários)
- correu
fixtime.plsem um argumento para ver que havia um segundo bissexto definido - correu
fixtime.plcom um argumento para remover o segundo bissexto
NOTA: depende de adjtimex. Eu coloquei uma cópia do adjtimexbinário squeeze em http://linux.brong.fastmail.fm/2012-06-30/adjtimex — 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 do sistema não estiver presente. Obviamente, se você não tiver o squeeze de 64 bits… encontre o seu próprio.
Vou recomeçar ntpamanhã.
Como um usuário anônimo sugeriu - uma alternativa à execução adjtimexé apenas definir a hora, o que presumivelmente também limpará o contador de segundos bissextos.