Saltar para o conteúdo 
Com o kdump, podes preparar um servidor Linux para guardar uma imagem de memória no caso de uma falha adequada do kernel. Para uma análise posterior, precisas do vmcore, de um vmlinux compatível com a compilação do kernel que sofreu a falha, com informações de depuração, e de uma ferramenta crash compatível. O Preparação antes da queda É fundamental: sem uma cópia de segurança, não é possível reconstruir posteriormente o estado da memória que se perdeu. Mesmo um dump existente é apenas um instantâneo; um único quadro da pilha não prova, por si só, a causa.
O que o kdump regista quando o kernel entra em falha
O kdump prepara a criação de uma cópia de segurança de uma imagem da memória do kernel do Linux antes de ocorrer uma falha. Para tal, é reservada uma área de memória aquando do arranque do kernel normal. Nessa área é criada uma Kernel de captura carregado, que pode ser iniciado através do kexec em caso de uma falha adequada.
O kernel Capture funciona independentemente do kernel do sistema que sofreu uma falha e obtém acesso à sua imagem de memória através de /proc/vmcore. Pode gravar essa imagem num destino configurado. O ficheiro guardado é normalmente denominado vmcore; o facto de este conter todas as áreas de memória originais depende, entre outros fatores, da filtragem selecionada.
As funções são distintas: o kdump regista e guarda o estado, enquanto o programa acidente analisar posteriormente um dump existente. Isso permite, por exemplo, examinar mensagens do kernel e pilhas de tarefas. Um dump é, neste contexto, um instantâneo e não fornece automaticamente o histórico completo do erro.
Um «Oops» do kernel não é sinónimo de «Kernel Panic»: um «Oops» pode ocorrer sem que o sistema entre imediatamente em «Panic». Por isso, nem todas as falhas do kernel resultam na geração de um kdump. Por outro lado, um «core dump» de uma aplicação diz respeito ao estado de um processo e não é um «vmcore» do kernel.
Esta preparação é fundamental para a análise posterior. Se, no momento da falha, não estivesse preparado nenhum kernel de captura ou não tivesse sido guardada nenhuma imagem, o kdump não conseguirá reconstruir posteriormente o estado da memória perdido. Nesse caso, os registos existentes e outros dados de diagnóstico preservados após o reinício servirão de ponto de partida.
Condições e limites do registo
Esclareça primeiro a distribuição, a versão e a arquitetura do servidor. Desses fatores dependem os nomes dos pacotes, o controlo dos serviços, a configuração de arranque e os destinos de armazenamento suportados. Para a configuração, utilize a documentação específica desta plataforma, em vez de combinar comandos de diferentes distribuições; o hardware e os controladores instalados também influenciam os requisitos.
O parâmetro de arranque crashkernel estabelece a Reserva de espaço de armazenamento para o registo de falhas. Esta área não está disponível para o funcionamento normal. Não é fiável definir um valor fixo: orienta-te pelas especificações relativas à distribuição, à arquitetura e ao equipamento específico e tem em conta as necessidades de memória do sistema de captura.
A memória reservada, por si só, não é suficiente. O kernel de captura tem de estar carregado e de poder aceder ao destino configurado. Para tal, os controladores e componentes necessários têm de estar disponíveis no seu ambiente; no caso de um destino de rede, a ligação e a disponibilidade do ponto de ligação remoto também fazem parte dos pré-requisitos.
Preveja capacidade suficiente no destino para as imagens esperadas e para o seu armazenamento. O tamanho de um dump depende, entre outros fatores, do conteúdo da memória e da filtragem. Um destino cheio ou inacessível pode impedir a cópia de segurança, mesmo que a reserva esteja definida corretamente.
Mesmo uma instalação preparada não é garantia de um dump utilizável. Um «Oops» não desencadeia necessariamente um «Panic»; em caso de perda total de energia, o kernel de captura deixa de funcionar. Da mesma forma, uma falha grave de hardware pode impedir o seu arranque ou a gravação da imagem. A captura e o destino devem, por isso, ser considerados separadamente da causa real da falha.
Que ficheiros são considerados para a análise
Para a análise, não basta apenas o ficheiro de despejo. Se possível, guarde também os ficheiros de kernel e os registos associados, para que seja possível comparar o estado no momento da falha com as mensagens e as alterações. A seguinte síntese distingue a imagem de memória propriamente dita dos ficheiros auxiliares que permitem a sua análise.
| Artefacto | Conteúdo | Benefício | Restrição |
|---|---|---|---|
| vmcore | Imagem de memória do kernel protegida | Base da análise de dump | Podem faltar áreas filtradas |
| vmlinux com informações de depuração | Ficheiro do kernel com símbolos e informações de depuração | Atribui conteúdos de memória e funções ao kernel | Tem de corresponder à versão que falhou |
| Mensagens do kernel | Mensagens do kernel apresentadas | Apresentar acontecimentos e indicações antes do Panic | Não é necessariamente exaustivo nem causal |
| Registo do kernel de captura | Notícias da fase de recolha de dados | Ajuda em caso de problemas com o backup | Só pode ser utilizado se tiver sido criado e mantido |
| Informações de depuração do módulo | Símbolos e informações de depuração para módulos | Aprofundar a análise dos fatores envolvidos | Têm de ser compatíveis com os módulos utilizados |
Isto é particularmente importante vmlinux adequado: A arquitetura e a compilação exata do kernel devem corresponder ao kernel do sistema que sofreu uma falha. O kernel em execução após o reinício pode ser outro. A saída de uname -r No servidor recém-iniciado, isso não é, portanto, suficiente para selecionar o ficheiro correto para o dump antigo.
Além disso, utilize uma versão do crash compatível com o kernel e o formato do dump. Caso sejam relevantes controladores externos ou adicionais, tenha também à disposição os respetivos ficheiros de módulo e informações de depuração. Se faltarem símbolos ou se as páginas de memória necessárias tiverem sido filtradas, a análise poderá ficar limitada; essas lacunas devem ser incluídas na documentação dos resultados.
Um vmcore pode conter informações confidenciais da memória principal. Por isso, restrinja o acesso, proteja a transmissão e defina prazos de conservação e eliminação. Antes de enviar um dump ou registos complementares a um serviço de assistência, esclareça a autorização necessária para o efeito e o âmbito permitido.
Preparar o kdump no servidor
O ponto de partida é a distribuição, a versão e a arquitetura do servidor. Consulte a documentação correspondente para verificar quais os pacotes necessários para o kdump e para carregar o kernel de captura, bem como a forma de configurar o serviço. As instruções para as diferentes distribuições não são intercambiáveis: os nomes dos pacotes, a configuração de arranque e as ferramentas de verificação podem variar.
A preparação inclui a escolha da Reserva de espaço de armazenamento sobre o parâmetro de arranque crashkernel. Escolha o tamanho e, se necessário, outras configurações de acordo com as especificações da plataforma e do hardware em questão. A memória reservada não está disponível para o sistema em funcionamento normal; por isso, indicar um tamanho universal seria tão pouco útil como copiar sem verificar as configurações de outro servidor.
Após a configuração de arranque específica da plataforma e, se necessário, um reinício, o seguinte comando do shell em modo de leitura apresenta os parâmetros do kernel atualmente em execução. Procure na saída por crashkernel. Uma entrada mostra a configuração passada, mas não comprova nem que o kernel de captura tenha sido carregado nem que a gravação tenha sido bem-sucedida.
No RHEL 9, também podes verificar o estado com o seguinte comando no shell. Noutras distribuições, utiliza o método de verificação aí documentado. Um resultado positivo Mensagem de estado é um indício importante da disponibilidade, mas não substitui um teste controlado de todo o percurso de segurança.
Verifica também se o destino previsto e os controladores necessários para o efeito estão disponíveis no sistema de captura. Regista as definições selecionadas e a data da verificação, para que possas reavaliá-las após alterações no kernel ou na infraestrutura. Deves verificar as definições específicas para a plataforma de destino efetivamente utilizada antes da implementação.
Selecionar o destino da cópia de segurança e o âmbito do dump
O Objetivo de segurança tem de estar acessível durante a recolha e dispor de espaço livre suficiente. Um destino local evita a dependência de uma ligação de rede, mas requer espaço de armazenamento útil no servidor. Tenha também em conta que vários dumps guardados e ficheiros de diagnóstico associados podem ocupar espaço.
O RHEL 9 documenta, além de destinos locais, também destinos em rede através do NFS ou do SSH. Isto permite que o ficheiro seja armazenado separadamente do servidor em questão; para tal, é necessário que a rede, o sistema de destino e os componentes necessários no sistema de captura estejam a funcionar. Verifique as respetivas restrições da configuração específica do RHEL, em vez de equiparar a acessibilidade em funcionamento normal à do sistema de captura.
| Objetivo | Vantagem | Dependência importante |
|---|---|---|
| Local | Não é necessária ligação à rede para escrever | Armazenamento local utilizável e componentes de armazenamento disponíveis |
| NFS | Arquivamento num destino de rede | A rede e o terminal NFS devem estar acessíveis |
| SSH | Transmissão para um terminal remoto | A rede e o servidor SSH de destino têm de estar acessíveis |
Com makedumpfile é possível comprimir a imagem e filtrá-la de acordo com áreas de memória selecionadas. Filtragem pode poupar espaço de armazenamento e volume de transferência, mas elimina páginas que poderão vir a faltar numa análise posterior. Por isso, adapta o âmbito do dump ao diagnóstico previsto e documenta os filtros utilizados; o ficheiro mais pequeno não é, automaticamente, o mais útil.
Um vmcore pode conter informações confidenciais da memória principal. Por isso, restrinja o acesso, proteja a transmissão e defina durante quanto tempo os ficheiros devem ser conservados e quando devem ser eliminados. Antes de os transmitir a um serviço de assistência, certifique-se de que dispõe da autorização necessária; isto aplica-se igualmente a cópias armazenadas separadamente.
Abrir um ficheiro vmcore existente com o comando crash
Para a análise posterior, precisas do vmcore existente, que seja compatível com a compilação do kernel que sofreu a falha e com a arquitetura vmlinux com informações de depuração bem como uma versão do crash compatível com o kernel e o formato do dump. O kernel em execução após um reinício pode ser outro; por isso, a indicação da sua versão, por si só, não identifica de forma fiável a compilação que sofreu uma falha.
O comando esquemático seguinte deve ser executado no shell normal do sistema de análise. Substitua ambos os caminhos pelos ficheiros que existem efetivamente. O comando abre uma imagem existente para análise; não cria um dump nem configura o kdump.
Após um início bem-sucedido, irás trabalhar no mensagem de falha, já não no shell normal. Aí, o log as mensagens do kernel disponíveis. Comece por procurar a mensagem de pânico e o contexto temporal em que surgiu; as mensagens podem fornecer um ponto de partida, mas não descrevem necessariamente a causa completa.
Com bt analisas a pilha do contexto de análise atual; bt -a Mostra as pilhas das tarefas ativas nas CPUs. Compare as cadeias de chamadas com as mensagens, em vez de considerar um único quadro como prova de culpa. Dependendo do estado e da extensão do dump, podem faltar informações.
Na mesma linha de comando, pode-se utilizar ps na visão geral das tarefas; kmem -i fornece informações gerais sobre a memória. Este instantâneo, por si só, não prova nem a existência de uma fuga de memória nem a sua causa. Se for necessário analisar mais detalhadamente um módulo envolvido, poderão ser necessários, adicionalmente, os ficheiros do módulo e as informações de depuração correspondentes.
Organizar pilhas e notas de memória
Se ocorrer um «panic» após uma alteração no controlador, regista, em primeiro lugar, a hora, a compilação do kernel que falhou e os módulos envolvidos. Compare estes dados com o registo de alterações: foi atualizado apenas o controlador ou foi instalado, ao mesmo tempo, um novo kernel? Desta forma, poderá identificar quais as alterações relevantes para a investigação.
Em seguida, lê com log as mensagens do kernel disponíveis e analise-as com bt a pilha do contexto de análise atual. bt -a complementa a visão das tarefas ativas das CPUs. Além do texto do «Panic», anota também as mensagens que antecederam o «Panic»; estas podem fornecer o contexto de um erro que venha a ser visível posteriormente.
A Estrutura do driver A presença na pilha é um indício, mas não uma prova de culpa. Por exemplo, uma danificação anterior da memória só pode ser detetada numa função do controlador. Por isso, verifica se as mensagens, os módulos envolvidos e o fluxo de eventos se encaixam antes de considerares uma alteração como a causa.
Em caso de suspeita de armazenamento, fornece kmem -i uma visão geral das informações de memória, na medida em que o dump e a ferramenta as disponibilizem. Analise estes valores em conjunto com as mensagens do kernel. Um único valor não prova, por si só, a existência de uma fuga de memória nem identifica a sua causa; além disso, as páginas de memória necessárias podem estar em falta devido à filtragem.
Para determinar se o consumo aumenta ao longo do tempo, são necessárias séries temporais complementares. Numa análise separada da carga da CPU, é possível Perfilagem da CPU com a ferramenta Perf do Linux ajudar. Estas medições complementam o crash dump, mas não substituem o estado registado no mesmo no momento da falha.
Se não existir um vmcore utilizável
Após um bloqueio seguido de um reinício, é necessário esclarecer, em primeiro lugar, se ocorreu efetivamente um erro de pânico e se foi guardado um ficheiro vmcore. Um reinício, por si só, não comprova nenhuma das duas situações. Procura mensagens que correspondam ao momento do incidente e verifica o local de armazenamento configurado antes de concluíres que existe um erro específico apenas com base na ausência de um ficheiro.
Analisa o Cadeia de registo À parte: Estava carregado um kernel de captura no sistema em questão e o evento era adequado para acionar o kdump? Nem todos os «oops» resultam num «panic». Além disso, uma perda total de energia ou uma falha grave de hardware pode impedir que o kernel de captura seja iniciado ou que escreva dados.
Em seguida, verifica o destino da cópia de segurança: era acessível, havia espaço suficiente disponível e o sistema de captura incluía os controladores e componentes necessários? No caso de um destino em rede, a ligação e o ponto de ligação são dependências adicionais. No RHEL, o ficheiro kexec-dmesg.log Fornecer informações sobre a fase de registo, caso esta tenha sido criada e guardada.
Na ausência de um dump utilizável, os registos anteriores ou as mensagens persistentes da consola e do kernel constituem alternativas importantes. No entanto, estas fontes não fornecem uma imagem completa da memória; o estado perdido não pode ser reconstruído posteriormente com o kdump.
Se houver mensagens ou outras observações que indiquem problemas na rede, pode ser necessário realizar uma Análise da utilização do SoftIRQ no Linux ajudar na classificação do processamento de pacotes. Responde a uma questão diferente da verificação do destino do dump e, por si só, não comprova nem a existência de um «panic» nem a causa de uma cópia de segurança falhada.
Testar a recolha de dados e validar os resultados
Escolha o âmbito do dump de acordo com a questão de diagnóstico prevista e os recursos disponíveis. A compressão e a filtragem podem poupar espaço de armazenamento e reduzir o volume de transferência; no entanto, as páginas de memória removidas deixam de estar disponíveis para análises posteriores. Documente esta decisão, para que, durante a análise, seja possível identificar quais os dados que possam estar em falta.
Um vmcore pode conter informações confidenciais da memória. Por isso, regula o acesso, a transmissão protegida e o período de conservação, bem como o armazenamento dos ficheiros de depuração correspondentes. Antes de o enviar a um serviço de assistência, esclarece a autorização necessária e o tratamento previsto para os dados.
Verifica novamente a preparação caso haja alterações no kernel, nos controladores, na configuração de arranque ou na infraestrutura de cópias de segurança. Isto inclui o kernel de captura carregado e a acessibilidade do destino selecionado. Uma mensagem de estado positiva é útil, mas, por si só, não indica se, nas condições atuais, é efetivamente gerado um dump analisável.
Aviso: Um teste controlado de ponta a ponta provoca deliberadamente uma falha e pode causar reinícios e perda de dados. Realize-o apenas num ambiente de teste autorizado ou numa janela de manutenção preparada, com cópia de segurança dos dados. Esclareça previamente as responsabilidades, as consequências e o reinício; para tal, não é fornecido, deliberadamente, um comando de ativação.
Um significativo Teste de ponta a ponta Não te limites à verificação do estado: verifica se o ficheiro chegou ao destino previsto e se é possível abri-lo com os ficheiros correspondentes à compilação registada. Durante a depuração do servidor, registe os resultados, os dados em falta, as incertezas e os próximos passos de verificação. Ao fazê-lo, separe claramente as indicações observadas das causas ainda não confirmadas.
Fontes e estado atual dos conhecimentos
Estado da pesquisa:
Data da pesquisa e da documentação: 4 de novembro de 2026. Os exemplos específicos da distribuição referem-se ao RHEL 9; verifique as configurações para a sua própria plataforma antes da implementação.
https://docs.kernel.org/admin-guide/kdump/kdump.html
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/analyzing-a-core-dump_assembly_managing-kernel-command-line-parameters-with-uki
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/managing_monitoring_and_updating_the_kernel/index
https://crash-utility.github.io/help_pages/log.html
https://crash-utility.github.io/help_pages/bt.html
https://crash-utility.github.io/help_pages/kmem.html
