事情本身不复杂，线索都在日志里。一台自建机房的 CentOS 7.9 在凌晨失去响应，KVM 上看到内核 Oops 之后停在原地，kernel.panic 的值是 0，机器一直挂到第二天人工重启。
第一反应是「带外管理没有配置自动复位策略」，验证下来不成立。
排查方向其实有限，先把可能性排一排。kernel.panic 为 0 表示崩溃后不自动重启，内核停在 panic 现场。另一种情况是panic_on_oops 没开，部分错误只记录不触发重启。
还有一种情况，kdump 保留了现场，但没人去看 vmcore。
动手时先看当前的崩溃策略
sysctl kernel.panic kernel.panic_on_oops接着设置十秒后自动重启
sysctl -w kernel.panic=10 && sysctl -w kernel.panic_on_oops=1再往下写进持久化配置
printf 'kernel.panic = 10\nkernel.panic_on_oops = 1\n' > /etc/sysctl.d/99-panic.conf末了确认 kdump 能留下现场
systemctl is-active kdump && ls -lh /var/crash | tail -3怎么算真的好了，看的是同一批现象。人为触发一次软锁死后机器在十秒内自动重启，业务恢复，/var/crash 下留有对应的 vmcore 目录可供分析。
容易忽略的是，自动重启只是保住可用性，根因还得靠 vmcore 分析；panic 时间别设太短，给 kdump 留出写盘的时间。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。