Linux: Como diagnosticar / isolar o que está causando travamentos "aleatórios" e reinicializações espontâneas?

20

(publicado originalmente em serverfault )

Então, em vez de adivinhar qual é a causa (embora meu dinheiro esteja nos drivers da nvidia), onde começo a procurar descobrir alguns fatos?

Eu já passei por / var / log em várias ocasiões, mas há muitas coisas lá e ainda não consigo identificar os bits importantes.

Contexto: A versão curta

Mudei do WinXP para o Ubuntu Karmic logo após a disponibilização.

Desde então, tive uma série de falhas aparentemente aleatórias que se manifestam como:

uma reinicialização espontânea
um bloqueio completo com o teclado e o mouse USB sem resposta (até os LEDs todos apagando). Além disso, normalmente não consigo ssh na caixa quando isso acontece.

Eu fiz muitas pesquisas e a Nvidia parece ser o principal suspeito, mas não tenho idéia de por onde começar a procurar descobrir qual é a verdadeira causa.

Um usuário com falha no servidor sugeriu verificar a RAM com o MemtextX86 +. Nenhum erro encontrado. Também foi sugerido o monitoramento da temperatura da placa de vídeo, no qual estou analisando agora.

Além de sugestões, alguém?

Antecedentes: A versão longa

Às vezes, posso passar uma semana inteira sem problemas e ter 5 em 2 dias.

Motivado pelo desejo de eliminar possíveis suspeitos, fiz algumas alterações ao longo do tempo sem sucesso:

Originalmente, usei o KVM para virtualização, agora uso o VirtualBox OSE
Eu tinha o NFS rodando no kernel, mas agora uso o Samba
Eu estava usando o Compiz, mas desliguei isso
Eu passei do Karmic de 64 bits para o de 32 bits (por outras razões também)
Eu tentei o Ubuntu, Kubuntu e Xubuntu. O mesmo problema toda vez (embora ultimamente pareça ser mais frequente no Gnome do que no XFCE).
Rolei o driver da Nvidia da versão 185 para a versão 96 (Módulo do kernel da NVIDIA Linux x86 96.43.13 e quinta-feira 25 de junho 18:42:21 PDT 2009). Isso parece ter reduzido a frequência do erro.

Em termos do que está sendo executado no momento, isso pode variar. A seguir, são comuns, mas não estavam necessariamente em execução para cada falha:

Firefox 3.5
VirtualBox OSE com 1 ou 2 VMs do Windows XP
Skype
Rhythmbox ou Exaile

Meu hardware tem de 2 a 3 anos:

Core 2 Duo 6300
4GB RAM
alguma raça de placa-mãe Intel desse vintage
uma placa de vídeo Asus de cabeça dupla com chipset Nvdia GeForce 7300 GS
2 HDDs SATA
monitores duplos (por isso eu confio nos drivers proprietários da nvidia)

Eu tenho me mantido atualizado com as atualizações do meu sistema.

Esperamos que os dados acima possam levar alguém a sugerir um tipo específico de log ou configuração que valha a pena investigar.

Atualização 1

apenas teve um acidente em que os alto-falantes enlouqueceram. Pesquisei no Google e parece que o PulseAudio teve alguns problemas no passado. Ainda não tenho certeza se isso é relevante, mas o PulseAudio estará em execução toda vez que ocorrer um acidente.

Atualização 2

Seguir o link do @ CarlF para o Guia Debian Sysadmin me levou à chave sysrq mágica que tentarei na próxima falha. Não que isso me dê muitas pistas sobre a causa, mas pelo menos espero ser capaz de desligar normalmente.

Atualização 3

O lm-sensores relata minha GPU rodando a quase 70C / 158F - interessante. Se eu tivesse que adivinhar, diria que essa é uma pista importante.

Atualização 4

Bata no interior do sistema com um airduster logo após a minha última atualização - resultado líquido: apenas um acidente desde então. Vou chamar isso de um problema térmico.

— LRE
fonte

3

Excelente formatação e informações básicas, desejo que todas as perguntas sejam assim. +1.

— John T

8

Há bons conselhos no Guia do Administrador Debian aqui: http://www.debian-administration.org/articles/492

— CarlF
fonte

Interessante ver o que eles têm a dizer sobre logs não informativos serem um sinal de um problema real de hardware. Eu tenho um intervalo de seis horas entre a última entrada / var / log / message e a reinicialização. Hmmmm.

— LRE

aceito com o argumento de que o link deixou claro que nada nos logs é igual a problema de hardware - me leva na direção certa.

— LRE

4

A primeira coisa que você pode querer verificar se há problemas de hardware durante a inicialização. O processo de inicialização registrará dados do buffer de anel do kernel no /var/log/boot.log. Após a inicialização do sistema, novas mensagens são liberadas nesse buffer e você pode ver o estado atual com o dmesgcomando Um registro importante que você também deseja investigar é /var/log/messages. Isso conterá registros de data e hora, instalações e as prioridades dos erros e o aplicativo que os gerou. Ter um registro de data e hora disponível é um recurso inestimável ao depurar erros.

Os bloqueios aleatórios definitivamente parecem relacionados ao hardware. Tente recolocar todo o hardware na placa-mãe e execute o memtest86 + .

— John T
fonte

Eu vejo uma linha em / var / log / messages que diz "imklog 4.2.0, origem do log = / var / run / rsyslog / kmsg iniciado". Este é um bom indicador de uma inicialização do sistema? Nesse caso, posso usar isso para identificar uma área do log da qual posso digitalizar novamente.

— LRE

Sim, acredito que seja uma das primeiras, se não a primeira linha, após uma inicialização. É o módulo de entrada de log do kernel.

— John T

2

Você já tentou reinstalar sua memória, processador e outros chips? Além disso, você pode tentar executar outro SO (FreeDOS) para eliminar algumas possibilidades.

Como dica, você também deve poder usar dois monitores muito bem no Gnome sem usar os drivers da nvidia.

— Nerdfest
fonte

melhor que pude dizer que definitivamente preciso dos drivers proprietários da nvidia para usar monitores duplos. Você é capaz de me apontar na direção certa para não precisar deles?

— LRE

Eu posso estar incorreto. Eu bisbilhotei um pouco, e vejo referências ao xinerama (para as quais acho que o driver possui extensões), mas nada relacionado a drivers não proprietários. Infelizmente, não tenho uma máquina com uma placa nVidia para brincar.

— Nerdfest