0

KDUMP

0 Flares 0 Flares ×

Substituto do LKCD, o KDUMP existe para suprir as diversas limitações do seu antecessor. Ele é uma ferramenta extremamente flexível que estende suas capacidades permitindo o uso de NFS, CIFS, FTP e SSH para copia dos dump’s. Ele foi feito para o uso em larga escala sem restrição quanto a redes e sub-nets. (da pra notar que o LKCD é bem limitado…)

COMO O KDUMP TRABALHA?

O KDUMP trabalha com dois componentes básicos.

KEXEC

O Kexec é um mecanismo de fastboot que ignora as etapas de bootloader e inicialização de hardware. Nesta implementação, o kexec permite a execução direta de um novo kernel em memoria apartir do kernel em execução.

KDUMP

O KDUMP é um moderno componente para captura do dump de memoria do kernel. O dump de memória é capturado a partir do contexto de um kernel recém inicializado. O Kdump utiliza o Kexec para inicializar esse segundo kernel sempre que o sistema falhar. Este segundo kernel, (inicializado devido a falha) é o responsável por capturar o dump da memoria do sistema em produção no momento da falha.

IMPORTANTE:

O kdump “deve permanecer” desativado (por default) e utilizado quando necessário. Se houver necessidade de utiliza-lo (como será descrito no documento). Desativa-lo após troubleshooting do problema.

REQUISITOS

São poucos os requisitos. Porem, existe uma dificuldade inicial que é basicamente “onde gravar os dados do dump” e a preocupação com o tamanho desse dado. Levando em consideração que o core é literalmente um dump de memoria, um servidor com 64 Gb demandaria no mínimo de 64 Gb + 2% de espaço para gravar este dump. Esta é a regra:

Sendo assim, precisaríamos de 65.28Gb (valor pode ser arredondado pra +)

Isso é muito importante. Se não for planejado o uso do kdump será apenas um novo problema em sua infra-estrutura. Portanto, valide este requisito e nunca esqueça que o espaço que será ocupado com o core dump é relativo a quantidade de memoria do servidor.

Em tempo, é requisito que o selinux esteja desativado e que seja instalado pacotes específicos.

 

Analisar o dump de memoria do momento do crash é fundamental para esse tipo trobleshooting. Com ele conseguimos uma analise efetiva do causador do “PANIC”. Ele é muito utilizado pela Redhat ou qualquer outro vendor para analise de problema quando o assunto é kernel PANIC. Porem, antes de encaminha-lo para analise do seu suporte, de a oportunidade a você mesmo e investigue o problema. Basta um pouco de pesquisa e paciência que você vai conseguir diagnosticar o problema.

Consideração quanto a analise dos dados (core dump)

Esta analise pode ser feita diretamente no servidor do dump. Porem, recomendado que esta analise seja feita em outro ambiente. Você não vai querer que sua analise seja interrompida caso o ambiente apresente nova falha, correto? Como esse tipo de evento é geralmente imprevisível… Melhor seguir esta recomendação a não ser que você não tenha muitas opções…

Iniciando a instalação do KDUMP no servidor… let’s go!

KDUMP SETUP

Execute a instalação dos seguintes pacotes:

# yum install kexec-tools

Grub.conf

Edit seu grub (grub.conf) e adicione o parametron “crashkernel=128M”. Esse parametro já existe nem sua configuração e provavelmente esta como auto. O parâmetro crashkernel define o tamanho de memoria que será utilizado pelo kernel “debug” que será inicializado pelo kexec.

# vi /boot/grub/grub.conf

linux /vmlinuz-3.1.4-1.fc16.x86_64 ro root=/dev/VolGroup00/LogVol00 rhgb LANG=en_US.UTF-8 crashkernel=128M

kdump.conf

Descomente o parâmetro “path” e especifique o filesystem/diretório que deseja gravar o dump. IMPORTANTE

Lembre-se do que foi comentado anteriormente… O tamanho do dump depende da quantidade de memoria que esta sendo utilizada. Nesta etapa, você pode criar um novo filesystem especifico para esta implementação e garantir que os dados possuem um espaço reservado sem impacto em caso de filesystem FULL para os demais componentes do sistema.

path /var/crash
core_collector makedumpfile -c –message-level 1

Ative e inicie o serviço:

# chkconfig kdump on

# chkconfig kdump start

OBS: Necessário boot para aplicar as configurações adicionadas no arquivo grub.conf

Validando se o suporte ao kdump esta ativo

# egrep ‘KEXEC|CRASH|CAL_S’ /boot/config*

Analise dos dados com o CRASH

Para analise dos dados do kdump, utilizamos o utilitário crash. Com ele conseguimos extrair as informações de stack dos processos no momento exato do Kernel Crash (panic). Assim, conseguimos de maneira efetiva determinar o causador seja ele hardware ou software.

Esta analise pode ser feita diretamente no servidor. Porem, recomendamos que seja preparado um ambiente de analise para que os dados sejam analisados com calma e é claro, com segurança

Instalando o crash no Redhat 6 Enterprise

Será necessário alterar o “subscription” do servidor em questão devido ao uso do canal “Server Debug Info e Extras DebugInfo”.

Com o canal devidamente configurado, execute a instalação do pacote:

# yum install yum-utils

Com o yum-utils instalado, execute o comando abaixo para iniciar a instalação das dependências necessárias para o uso do crash.

# yum install crash

# debuginfo-install kernel

 

Apartir desta etapa você já possui o ambiente adequado para analise. Vamos agora, em AMBIENTE de LAB força um kernel PANIC utilizando a SysRQ para concluirmos a analise e ter em mãos uma documentação pratica do uso do comando crash para trobleshooting. Não execute os comandos abaixo em ambiente produtivo a não ser que você saiba exatamente o que esteja fazendo. Neste caso, executando o “echo c” com a SysRQ ativa, você vai gerar um kernel panic independente do que esteja sendo executado em seu ambiente.

Forçando um “kernel panic” através da SysRq

Primeiramente, ative a SysRq com o comando:

# echo 1 >/proc/sys/kernel/sysrq

Após ativado, envie a trigger c para forçar o “panic”

# echo c >/proc/sysrq-trigger

 

Utilizando o commando crash para analise do arquivo de dump (vmcore)

Execute o crash informando o kernel debug e o vmcore gerando após panic.

crash /usr/lib/debug/lib/modules/2.6.32-279.el6.x86_64/vmlinux /kdump/127.0.0.1-2015-09-15-08\:34\:46/vmcore

Na interface do crash, será disponibilizado diversos comandos.

Com o comant bt, podemos especificar um processo e conseguir a informação do stack deste processo.

Executar o comando bt sem parâmetro será automaticamente especificado o processo causador do panic.

Este é o comando mais utilizado e geralmente, suficiente para conseguir analisar o stack de memoria do processo ofensor.

O que é possível fazer com o crash?

Verificar os processos

Execute o comando ps no prompt do crash para mostrar os processos em execucao no momento em que o systema entrou em PANIC.

Vierificar SWAP

Execute o comando swap no prompt do crash para mostrar o uso do swap no memento em que o Sistema entrou em PANIC.

Verificar IPCS

Execute o comando ipcs no prompt do crash para mostrar o shared memory no momento em que o Sistema entrou em PANIC.

Vizualizar as IRQ’s

Execute o comando irq no prompt de comando o crash para mostrar o status das irq’s no momento do kernel PANIC.

Verificar a memoria virtual

Execute vm command at the crash prompt, which will display the virtual memory usage when the system crashed.

Vizualizar os descritores de arquivos

Execute o comando files no prompt de comando do crash para mostrar os descritores de arquivos utilizados pelo SO no momento do kernel PANIC.

 

 

Informações do sistema no momento do panic

Execute o comando sys no prompt do comando do crash para mostrar as informações correspondentes ao sistema no momento do kernel PANIC.

Troubleshooting

Execute o comando crash:

Ao executar o comando com a sintaxe correta, o utilitário ira fazer parse do arquivo vmcore e gerar um resumo com as informações sobre o sistema e o principal, a “origem do PANIC” com informação do processo <pid> e o comando ofensor. No exemplo abaixo, executamos o panic forçando uma instrução com o sysRq, veja que a informação esta bem objetiva no print.


Ainda na console do crash siga a analise com o comando “bt”. (especificando o processo informando pelo crash na tela anterior <PID:>)

Veja que aqui temos o detalhe da instrução em memória e a causa do problema.

Espero que este documento seja útil. É muito incomum as ocorrências de “kernel panic”, o kernel Linux é estável e muito confiável. Porem, sempre devemos estar preparados para este tipo de troubleshooting.

Avelino Ferreira

"Meu egoísmo é tão egoísta que o auge do meu egoísmo é querer ajudar..."

Dúvidas? Deixe seu comentário ou entre em contato.