A depuração da máquina Linux congela

Question

Eu tenho 15 servidores idênticos do Linux RH 4.7 de 64 bits. Eles executam o banco de dados de cluster (cluster é nível de aplicativo). Na ocasião (a cada mês mais ou menos) uma caixa aleatória (nunca a mesma) congela.

Eu posso pingar a caixa e o ping funciona. Se eu tentar ssh na caixa eu recebo:

ssh_exchange_identification: Connection closed by remote host

O SSH está configurado corretamente.

Quando eu vou para a sala do servidor e tento logar diretamente no console, eu posso trocar de console com Alt + Fn , eu posso inserir um nome de usuário e caracteres mostre, mas depois de pressionar Enter , nada acontece. Esperei 8 horas uma vez e isso não mudou.

Eu configurei o syslog para registrar tudo em um host remoto, e não há nada nesses registros. Quando eu reinicio a máquina, ela funciona sem nenhum problema. Eu executei testes de HW - tudo está ok e nada está nos logs. As máquinas também são monitoradas com o NAGIOS, e não há carga ou atividade incomum antes do congelamento.

Eu fiquei sem ideias; o que mais posso fazer ou verificar?

    

Answer 1

Parece que seu kernel entrou em pânico de tal forma que o sshd não pôde enviar as chaves do servidor. Possivelmente, o kernel estava encravado de tal forma que a pilha de rede ainda estava ativa, mas a camada vfs estava indisponível.

Quando tive problemas semelhantes em um sistema RHEL4, configurei os serviços netdump e netconsole e um servidor de netdump e syslog dedicado para capturar os despejos de memória e as informações de kernel panic. Eu também configurei o sysctl kernel.panic para 10. Dessa forma, quando um sistema entra em pane, você obtém o rastreio do kernel e uma cópia da memória nesse sistema, para a qual você pode analisar com o utilitário 'crash'.

Você certamente também se beneficiaria da configuração de um console serial para os hosts, para que você pudesse ver a saída do console e potencialmente atingir as chaves do magic sysrq. Além disso, se você estiver disposto a configurar a rede e tiver um hardware compatível, poderá usar o IPMI para desligar, ligar, reiniciar e consultar o hardware remotamente.

(pelo que vale a pena, o RHEL5 tem uma funcionalidade semelhante com o kexec / kdump, apenas o despejo de memória é armazenado localmente)

    

Answer 2

Para mim, isso soa como se o sistema estivesse sem recursos, portanto, o processo necessário pelo lado do servidor do ssh não pode ser alocado.

O gargalo real pode variar - de processos ou de memória - e a única maneira de ter certeza é consultar os logs e o console para ver se há algo presente nele. Você pode querer configurar um cenário de tarefas ssh pré-iniciadas - uma para cada máquina - simplesmente para estar preparado na próxima vez que isso acontecer.

Se for realmente ruim, talvez você queira considerar iniciar outro shell com mais comandos internos para que possa investigar mais sem ter que iniciar um processo extra, pois isso pode não ser possível. Também "tail -f / var / log / *" pode ser muito útil.

Boa sorte.

    

Answer 3

Eu apostarei dólares em donuts que você está ficando sem memória. O sistema está parando enquanto tenta descobrir de onde tirar algum. Pode estar acontecendo tão rapidamente que o seu monitoramento não o pega. Eu aumentaria o monitoramento, incluindo o registro remoto de uso de memória. Verifique nos logs as mensagens do OOM também.

(Você pode até querer ter algumas janelas ssh abertas no topo.)

    

Answer 4

A única vez que vi algo parecido foi onde uma chave KVM foi usada e uma tecla de atalho do teclado (por exemplo, alt + n) foi usada para alternar entre os servidores. Isso não aconteceu todas as vezes e foi o servidor sendo desligado do que foi afetado - por isso não foi imediatamente perceptível. Nenhum bloqueio ocorreria se um botão físico no próprio switch KVM fosse usado para alternar entre os servidores. Se a tecla de atalho era usada com frequência, ocasionalmente um servidor não permitiria novos logins. As sessões SSH existentes não foram afetadas.