Tutoriais de VPS
O que fazer quando o VPS sofre Kernel Panic (2026): guia de diagnóstico com kdump, vmcore, journalctl e crash
O VPS reinicia sozinho de repente, o console mostra Kernel panic, o SSH não conecta ou os logs contêm kernel oops/call trace. As causas comuns incluem anomalias em módulos/drivers do kernel, problemas de sistema de arquivos ou partição raiz, erros de hardware de memória/CPU, falhas em cascata após OOM e incompatibilidade de initramfs após atualização do kernel. Este artigo investiga camada por camada usando os logs da inicialização anterior, dmesg, kdump, vmcore, crash e as evidências para o ticket do provedor.
Quando um VPS sofre um Kernel Panic, a primeira reação de muitas pessoas é: a máquina quebrou? O provedor caiu?
No console pode restar apenas uma tela em inglês:
Kernel panic - not syncing
Unable to mount root fs
Oops: 0000 [#1]
Call Trace:
RIP: 0010:...
Ou você nem viu a tela de panic, e só percebeu que o VPS reiniciou sozinho de repente, o serviço foi interrompido e, depois de reconectar via SSH, os logs estavam cortados. Nesse momento, não olhe apenas os logs da aplicação. Um Kernel Panic é uma falha no nível do kernel, então o foco do diagnóstico está nos logs da inicialização anterior, no ring buffer do kernel, nos despejos de falha e nas evidências do host/disco em nuvem/drivers.
Este artigo explica com clareza para o cenário de VPS: primeiro confirmar se é realmente um kernel panic, depois determinar se é o sistema de arquivos, a memória, os drivers, uma atualização do kernel ou um problema subjacente do provedor, e por fim explicar quando você precisa configurar o kdump e como enviar as evidências ao provedor.
Quando um serviço cai, o sistema continua vivo; um Kernel Panic é quando o próprio kernel do sistema não aguenta.
Primeiro veja os registros de reinicialização:
last -x reboot shutdown | head -n 20
Depois veja os logs de erro da inicialização anterior:
journalctl -b -1 -p err --no-pager
Se o sistema suportar journal persistente, você também pode ver o log completo do kernel da inicialização anterior:
journalctl -k -b -1 --no-pager
O que procurar:
journalctl -k -b -1 --no-pager | grep -Ei 'panic|oops|call trace|not syncing|segfault|mce|i/o error|ext4|xfs'
Se você só vê que um determinado serviço failed, isso não é necessariamente um kernel panic. Você pode ler primeiro: Como ler os logs de um VPS (journalctl, systemctl, Nginx, logs de aplicação).
Você não precisa ler os logs de Kernel Panic palavra por palavra; primeiro capture as palavras-chave.
Este é um kernel panic explícito. As causas comuns incluem:
- Falha ao montar o sistema de arquivos raiz
- Anomalias em módulos críticos do kernel
- O processo init não consegue iniciar
- O kernel encontra um erro irrecuperável
Isso geralmente está relacionado ao disco de inicialização, initramfs, fstab, atualização do kernel ou sistema de arquivos.
Cenários comuns:
- O initramfs não foi gerado corretamente após atualizar o kernel
/bootou a partição raiz apresenta anomalia- O nome do dispositivo do disco em nuvem mudou
- Corrupção do sistema de arquivos
Se você também vir sistema de arquivos somente leitura, fsck ou emergency mode, pode consultar: O que fazer quando o VPS se torna um sistema de arquivos somente leitura.
Oops não causa necessariamente um panic imediato, mas indica que o kernel encontrou uma anomalia grave. Call Trace é a pilha de chamadas, que ajuda a localizar qual módulo ou driver está com problema.
Por exemplo:
Oops: 0000 [#1] SMP PTI
Call Trace:
? some_driver_function+0x...
RIP: 0010:...
Se na pilha aparecer repetidamente o nome de um módulo, sistema de arquivos, driver de placa de rede ou módulo de kernel de terceiros, esse é o foco do diagnóstico.
Se você vir:
Machine Check Exception
Hardware Error
MCE
Esse tipo de log geralmente aponta para um problema de hardware ou no nível do host. Usuários de VPS não podem trocar diretamente a memória ou a CPU, mas podem enviar os logs ao provedor para que ele verifique o hardware do host, migre o nó ou substitua a instância.
Quando o sistema atual ainda está vivo, você pode ver:
dmesg -T | grep -Ei 'panic|oops|call trace|mce|hardware error|i/o error|ext4|xfs'
Mas se a máquina já sofreu panic e reiniciou, dmesg normalmente contém apenas os logs do kernel desde esta inicialização. Para ver a inicialização anterior, prefira:
journalctl -k -b -1
Isso exige que o journal persistente esteja habilitado. Se /var/log/journal não existir, muitos sistemas guardam apenas os logs da inicialização atual. Você pode habilitar a persistência:
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
Isso não vai ajudar a recuperar um panic antigo que já se perdeu, mas tornará a próxima falha mais fácil de rastrear.
Kernel Panics costumam ocorrer após uma atualização do kernel, especialmente quando:
- O disco encheu durante a atualização
/bootficou sem espaço- A geração do initramfs falhou
- Foi usado um módulo de terceiros incompatível
- A combinação de uma imagem de VPS antiga com um kernel novo é instável
Verifique os registros de instalação recentes:
grep -i 'install\|upgrade' /var/log/dpkg.log | tail -n 50
No Debian / Ubuntu você também pode ver o histórico do apt:
grep -i kernel /var/log/apt/history.log
Ver o kernel atual:
uname -a
Listar os kernels instalados:
dpkg -l | grep 'linux-image'
Se você conseguir entrar no GRUB pelo console do provedor, pode tentar inicializar com um kernel antigo. Não apague os kernels antigos de imediato; mantenha pelo menos uma versão que você confirmou que inicializa.
Um Kernel Panic não é necessariamente um bug do próprio kernel. Erros na partição raiz, no disco em nuvem ou no sistema de arquivos também podem arrastar o sistema para um panic.
Procure erros de E/S e de sistema de arquivos nos logs do kernel:
journalctl -k -b -1 --no-pager | grep -Ei 'i/o error|buffer error|blk_update|ext4|xfs|remount|read-only'
Se você vir muitos:
Buffer I/O error on dev vda
EXT4-fs error
XFS metadata I/O error
Você deve suspeitar primeiro do disco em nuvem, do sistema de arquivos ou do armazenamento do host. Nesse momento, não apenas reinicie. Faça backup enquanto os dados ainda são legíveis e, se necessário, entre em rescue mode para executar fsck ou migrar para um novo disco.
Usuários de VPS não veem o hardware do host, mas os logs do kernel às vezes revelam pistas.
Procure erros de hardware:
journalctl -k -b -1 --no-pager | grep -Ei 'mce|machine check|hardware error|edac|memory error'
Se aparecerem MCE ou erros de hardware, não é recomendável tentar consertar por conta própria dentro do sistema. Você deve:
- Salvar os logs.
- Registrar a hora e o fuso horário em que ocorreu.
- Abrir um ticket com o provedor.
- Solicitar que verifiquem o hardware do host, migrem o VPS ou troquem o nó.
Se você também vir steal time alto, oscilações no disco e vários usuários do mesmo nó afetados, pode combinar com: Como saber se um VPS está com overselling.
O comportamento padrão após um Kernel Panic depende da configuração do sistema. Alguns sistemas param na tela de panic, outros reiniciam automaticamente.
Ver a configuração:
sysctl kernel.panic
Se você quiser que ele reinicie automaticamente 10 segundos após um panic:
sudo sysctl -w kernel.panic=10
Configuração permanente:
echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kernel-panic.conf
sudo sysctl --system
Atenção: a reinicialização automática pode reduzir o tempo de inatividade, mas também pode mascarar a cena. Em sistemas de produção, recomenda-se combiná-la com alertas de monitoramento e kdump, não depender apenas da reinicialização automática.
Se os Kernel Panics ocorrem repetidamente, mas a causa raiz não aparece nos logs, você precisa do kdump.
A função do kdump é: quando o sistema falha, preservar um arquivo de despejo de memória vmcore, e depois analisá-lo com a ferramenta crash.
Instalação no Debian / Ubuntu:
sudo apt install kdump-tools crash linux-crashdump -y
RHEL / Rocky / AlmaLinux:
sudo dnf install kexec-tools crash -y
Após habilitar, confirme se o parâmetro crashkernel existe:
cat /proc/cmdline | grep crashkernel
Se o kdump está funcionando corretamente:
systemctl status kdump-tools
systemctl status kdump
O nome do serviço varia conforme a distribuição. Quando a memória do VPS é muito pequena, reservar o crashkernel ocupa parte da memória, então é preciso ter cuidado em máquinas pequenas com menos de 1 GB.
Se um vmcore for gerado com sucesso, o caminho comum pode ser:
/var/crash/
/var/lib/systemd/coredump/
/var/crash/127.0.0.1-YYYY-MM-DD-...
Para analisar com crash é necessário:
- O arquivo vmcore
- O vmlinux / debug symbols do kernel correspondente
O comando básico é semelhante a:
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore
Após entrar no crash, você pode usar:
bt
log
ps
kmem -i
sys
Para a maioria dos usuários de VPS, não é necessário entender completamente a saída do crash por conta própria. Uma abordagem mais realista é: confirmar que o vmcore foi gerado e enviar as informações principais junto com o ticket do provedor. Para equipes de negócio autogerenciadas, pelo menos é possível ver em bt e log se está relacionado a algum módulo, sistema de arquivos, driver ou erro de memória.
Não escreva apenas: "A máquina teve um Kernel Panic, por favor resolvam."
Um conteúdo de ticket melhor:
故障时间：2026-05-25 10:18 Asia/Shanghai
现象：VPS 自动重启，业务中断约 2 分钟
实例 ID：xxx
系统：Ubuntu 24.04 / kernel xxx
已确认：
- last -x 显示异常 reboot
- journalctl -k -b -1 中出现 Kernel panic / Call Trace
- dmesg 中有/无 I/O error
- MCE/Hardware Error 有/无
附件：
- journalctl -k -b -1 输出
- last -x reboot shutdown 输出
- vmcore（如有）
Se os logs contiverem I/O error, MCE ou anomalias de recursos do host, solicite explicitamente ao provedor que verifique o host, o disco em nuvem e as possibilidades de migração.
Ao encontrar um Kernel Panic ou reinicialização anômala de VPS, verifique nesta ordem:
last -x reboot shutdownpara confirmar o horário da reinicialização anômala.journalctl -b -1 -p errpara ver os erros da inicialização anterior.journalctl -k -b -1para procurarpanic/oops/call trace/mce/i/o error.- Verificar se o kernel, o initramfs ou módulos de terceiros foram atualizados recentemente.
- Procurar erros de sistema de arquivos e disco em nuvem:
ext4/xfs/i/o error/read-only. - Procurar erros de hardware:
mce/machine check/hardware error. - Se necessário, configurar
kernel.panic=10para reduzir o tempo de inatividade. - Se ocorrer repetidamente, configurar o kdump e coletar o vmcore.
- Usar o crash para obter informações básicas de
bt/log/sys. - Abrir um ticket com o provedor com a linha do tempo completa e os logs.
Um Kernel Panic não é uma queda comum de aplicação. Normalmente significa que ocorreu um problema irrecuperável no nível do kernel, do sistema de arquivos, do disco em nuvem, do driver, do hardware ou do host.
Primeiro use journalctl -k -b -1 e last -x para reconstruir a linha do tempo, depois use as palavras-chave para distinguir entre sistema de arquivos, atualização do kernel, erros de hardware MCE e anomalias de driver. Um panic pontual pode ser observado primeiro; se ocorrer repetidamente, é preciso configurar o kdump para guardar o vmcore e enviar as evidências ao provedor. Não dependa apenas de reiniciar para mascarar o problema, caso contrário o próximo pode ocorrer no horário de pico do negócio.