Como sei o que o servidor está fazendo ao travar?

Question

Eu tenho um servidor rodando no Centos 5.2 e existe uma maneira melhor de saber porque o servidor travou ou o que está fazendo naquele momento?

Me desculpe, eu sou um novato e qualquer ajuda é apreciada ~ Obrigado

    

Answer 1

Se você experimentou um kernel panic, você pode configurar um console remoto do kernel para capturar todos os dados que podem ser perdidos no console local (especialmente se a falha for de uma interrupção não-mascarável, que tende a reinicializar o sistema).

No sistema que você espera que possa falhar:

/sbin/modprobe netconsole [email protected]/eth0,[email protected]/00:19:BB:31:B8:0E

• 6666 é um número de porta arbitrário
• 10.1.1.16 é o endereço IP da interface local para enviar via
• eth0 é o nome da interface local para enviar via
• 10.1.1.17 é o endereço IP da interface remota para enviar para
• 00: 19: BB: 31: B8: 0E é o endereço MAC da interface remota para enviar para

No sistema remoto, execute (isso requer que você tenha o netcat instalado):

nc -l -p 6666 -u | tee capture.file

Isto irá capturar toda a saída do kernel no sistema remoto. Isso é executado em um nível muito mais baixo (o mesmo ponto no kernel que grava em / dev / klog), então você pode ver o último bit de informação que o kernel produz quando entra em pânico, mesmo se syslog et. todos pararam de operar.

    

Answer 2

tente iniciar a contabilidade do processo

/etc/init.d/psacct start ou /sbin/chkconfig psacct on (para início automático na inicialização)

use lastcomm (1) para ver o que estava sendo executado quando.

ou tente instalar o no topo , ele registrará a memória da sua máquina e o estado do processo a cada 10 minutos para que você possa ter uma ideia do que estava acontecendo.

atop -r /var/log/atop/atop_YYYYMMDD e, em seguida, use as teclas te T para ir para frente e para trás

em 99% dos casos, fica claro por esses dois exatamente o que estava acontecendo

    

Answer 3

Você verificou / var / log / dmesg, / var / log / messages e / var / log / syslog?

    

Answer 4

Que tipo de acidente? A recomendação de todos sobre os logs do dmesg / messages é boa. Se estiver apenas "desligando" antes que tenha a chance de fazer o log de qualquer coisa, eu acho que pode estar superaquecendo ou há um problema na fonte de alimentação.

Se esse for o caso, pode ser útil acessar os logs de hardware, se existirem. Se você usar servidores Dell, o suporte da Dell poderá fornecer a você ferramentas do Linux para acessar esses registros. Outros fornecedores podem fornecer funcionalidade semelhante.

Você também pode verificar a memória com memtest86 .

    

Answer 5

Coletar um núcleo na rede é provavelmente um exagero, você pode despejá-lo localmente. This é um guia para configurar e testar o kdump. Se você seguir as instruções e ainda não conseguir que um dump seja criado localmente, então deverá seguir para a captura pela rede.

É claro que, depois de ter um despejo principal, você precisará fazer algumas análises usando o acidente utilidade. Você precisará instalar o kernel-debuginfo rpm correto para o seu kernel em execução e invocar o travamento - você deve obter a essência geral do papel branco. Se você conseguir abri-la, a primeira coisa que você deve olhar é o log - role até o final e você deve obter algumas pistas sobre o que está acontecendo no momento em que a falha ocorre.

    

Answer 6

Você poderia configurar a máquina para fazer um dump do kernel na rede, mas ainda precisaria de alguém habilitado para investigar isso.