Por Jennifer Vesperman - 01/11/2001
Sua máquina Linux acabou de morrer, e seu up-time subiu no telhado. Como saber o que aconteceu, e mais importante, como evitar que o incidente se repita?
Este artigo não discute o espaço dos programas de usuário -- poucos deles
irão fazer o sistema sofrer um crash sem chance de recuperação, o único que eu
conheço que com certeza faz isto é o crashme. A maior parte dos
crashes são causados por "oopses" do kernel, ou falhas de hardware.
Um oops do kernel acontece quando o mesmo chega a um estado irrecuperável.
Na maioria dos casos, o kernel pode escrever seu status no drive, o que
permite que se determine o que aconteceu se você tiver as ferramentas
corretas. Em poucos cassos, como o crash Aiee, killing interrupt
handler, o kernel não consegue escrever no drive. Sem um gerenciador de
interrupções, I/O feita com interrupções é impossível.
Mesmo nos piores casos, alguns dados podem ser recuperados e a causa da falha geralmente pode ser determinada.
Ferramentas de diagnóstico são uma parte necessária da recuperação de erros
do kernel. A ferramenta mais óbvia é o log do sistema. O dmesg é
uma ferramenta bastante útil para recuperar os dados relevantes dos logs do
sistema e do kernel.
Há também uma ferramenta especializada em examinar oopses do kernel. O
ksymoops exige que o sistema esteja configurado da mesma forma
que estava quando ocorreu a falha, e deve ser usada o quanto antes possível
após o crash. Ele faz um trace da cadeia de funções, e mostra a função e o
endereço em que o kernel estava quando ocorreu o crash.
Com as informações do logo do sistema, ou (para maior precisão) do
ksymoops, um administrador de sistema pode determinar qual função
o kernel estava tentando executar quando ocorreu o crash. É então muito mais
fácil determinar se deve ser trocado um driver de hardware, ou carregar um
módulo diferente -- ou postar um relatório de erro para o desenvolvedor
relevante.
Se seu sistema ainda está rodando, você pode rodar o dmesg
para obter informações de diagnóstico do kernel que geralmente é jogada no
console. As mensagens também são escritas em /proc/kmsg, mas o
dmesg permite que você copie as mesmas para um outro arquivo para
examinar mais tarde ou para postar para um expert no kernel. O
dmesg também pode ser lido pela maioria dos usuários, enquanto
/proc/kmsg tem permissões limitadas.
dmesg > filename
Alguns argumentos úteis:
Configura o nível de mensagens a serem apresentadas no log de mensagens. 1 significa mensagens de kernel panic somente. 7 é tudo, incluindo mensagens de depuração de desenvolvedores
Limita o tamanho do buffer de mensagens
Imprime e esvazia o buffer de mensagens
O syslogd e o klogd são programas que registram a
atividade do sistema. O klogd cuida do registro de atividades
(log) do kernel, mas geralmente é montado junto com o syslogd e é
configurado com o mesmo. Os loggers em si são inúteis depois da depuração do
problema -- mas podem ser configurados para registrar mais dados no próximo
crash.
Use o arquivo /etc/syslogd.conf para determinar onde estão os
arquivos de log do sistema, e para ver onde os arquivos de log do kernel, se
/proc/kmsg não existir.
Se você estiver executando módulos carregáveis, o klogd deve
ser sinalizado quando os módulos são carregados ou descarregados. O fonte do
sysklogd inclui um caminho para o pacote modules-2.0.0 para
garantir que as funções que carregam e descarregam módulos sinalizem a
klogd corretamente.
A partir do modutils 2.3.1, o log de módulos é interno. Para usar o log,
crie /var/log/ksymoops, com o root como owner e com o
modo "644" ou "600". O script insmod_kysmoops_clean irá excluir
versões antigas, e deve ser executado como uma tarefa cron.
Quando o kernel detecta um erro irrecuperável ou um erro sério, ele imprime um relatório de status no arquivo de log do kernel. Este relatório inclui coisas como o conteúdo dos registradores, o conteúdo do stack do kernel, e um function trace das funções em execução no momento da falha.
Tudo isto é extremamente útil -- mas está em formato que só a máquina pode
ler, e os endereços variam dependendo da configuração das máquinas
individuais. Assim, o log do kernel sozinho é inútil para determinar
precisamente o que aconteceu de errado. É aí que o ksymoops
entra.
O ksymoops converte o relatório que está em formato legível
apenas pela máquina para um relatório que possa ser lido por um humano. Ele se
baseia em um arquivo System.map correto, que é gerado como parte
da compilação do kernel. Ele também espera que o klogd trate os
módulos carregáveis corretamente, se for o caso.
O ksymoops ocupa o "texto oops", normalmente disponível como
Oops.file no logger do sistema. Se o arquivo não pode ser
encontrado, copie o texto oops de dmesg, ou do console -- copia à
mão, se necessário.
A saída do ksymoops é uma lista de mensagens que pode conter
um problema de kernel. Onde possível, o ksymoops converte os
endereços para o nome da função em que o endereço ocorre.
>>EIP; c0113f8c <sys_init_module+49c/4d0>
Trace; c011d3f5 <sys_mremap+295/370>
Trace; c011af5f <do_generic_file_read+5bf/5f0>
Trace; c011afe9 <file_read_actor+59/60>
Trace; c011d2bc <sys_mremap+15c/370>
Trace; c010e80f <do_sigaltstack+ff/1a0>
Trace; c0107c39 <overflow+9/c>
Trace; c0107b30 <tracesys+1c/23>
Trace; 00001000 Before first symbol
Estas linhas são explicadas em grande detalhe em man ksymoops,
mas o que é maisimportante para a maior parte dos administradores de sistema é
a lista de nomes de função em que os problemas ocorreram. Uma vez que você
conheça a função chave, e a função que a chamou, você pode fazer uma
adivinhação mais informada sobre a causa do erro do kernel.
Tenha cuidado que a saída do ksymoops é tão boa quanto o
arquivo de entrada -- se o arquivo System.map estiver errado, os
módulos não irão gerar um relatório quando forem carregados na memória, ou os
arquivos vmlinux, ksyms, lsmod e
objetco são diferentes dos presentes quando o crash do sistema
ocorreu, o ksymoops não irá produzir um relatório válido. Você
deve executar o mesmo assim que possível após o crash, para usar os dados mais
preciso -- e certamente antes de trocar o kernel!
Se você é um programador C experiente, você pode querer depurar o kernel
você mesmo. Use a saída do ksymoops para determinar onde o
problema está no kernel, e então use o gdb para desassemblar a
função problemática e depurar a mesma.
gdb /usr/src/linux/vmlinux
gdb> disassemble offending_function
Você descobrir que o problema é algo que você pode corrigir, talvez um driver ou um módulo carregável. E agora?
Instale todos os patches apropriados, verifique se o driver está correto -- e recompile o kernel e acrescente o mesmo a uma nova entrada no lilo. Teste o novo kernel. Se ele não corrigir o problema, considere relatar o problema na lista linux-kernel, ou para o desenvolvedor do kernel apropriado.
Se você está relatando um bug para a lista de mail Linux Kernel, ou para algum dos desenvolvedores do kernel Linux, coloque as informações em linux-kernel@vgter.kernel.org, ou para o desenvolvedor relevante, com o assunto "ISSUE: resumo de uma linha para [1.]".
/proc/version):
ksymoops:
ver_linux de
$LINUXHOME/scripts/ver_linux)
/proc/cpuinfo)
/proc/modules)
/proc/scsi/scsi)
/proc e inclua toda informação que você achar que é relevante):
Note que o linux-kernel FAQ avisa que os dados do Oops são inúteis se a
máquina na qual ocorreu o oops está com over-clock, ou está rodando o
vmmon da VMWare. Se você tem um destes, corrija o problema e
tente reproduzir o Oops antes de relatar o mesmo.
Se você tem erros repetidos, aparentemente aleatórios, pode ser que o ventilador da CPU esteja estragado. Se você está familiarizado o suficiente com o equipamento, você pode ouvir se o ventilador está funcionando -- se não, o teste mais simples é abrir a caixa do computador e olhar. Se o ventilador da CPU não está funcionando, desligue a máquina e troque o ventilador -- você pode ter salvo a CPU.
Se o ventilador da CPU está funcionando, mas você ainda tem erros randômicos, suspeite da RAM. Existem duas formas comuns de testar a RAM. Uma é remover a memória suspeita e experimentar com outra memória, ou testar a memória suspeita em uma máquina que já se sabe que funciona. Outro teste é fazer a recompilação do kernel repetidamente. Se você receber um signal 11, então a RAM provavelmente está com problemas.
A última causa comum de falha de hardware são bad blocks no disco rígido.
Use o programa badblocks para testar o drive.
Com um pouco de cuidado, e um ouco de sorte você pode conseguir o up-time record de seu LUG local -- a menos que uma falha de energia derrube sua máquina. Mas eu não posso ajudar você com isto!
man ksymoops
man dmesg
man syslogd
man klogd
man insmod
$LINUXDIR/linux/Documentation/oops-tracing.txt
$LINUXDIR/linux/README
man gdb
info gdb
Versão inglesa oreillynet.com Copyright © 2000 O'Reilly & Associates, Inc.
Tradução do original em http://www.oreillynet.com/pub/a/linux/2001/11/01/postmortem.html