记录一下那天晚上的排查过程。一台 CentOS 7 按安全加固清单加了 kernel.panic_on_oops=1，某天业务高峰期机器无故重启，vmcore 里能看到一次驱动的 WARNING 调用栈。
刚开始盯着「panic 之后配置了自动重启，机器起来看起来像无故重启」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。panic_on_oops 让内核在遇到 oops 时直接 panic，而 WARNING 也会走到这条路径。还有一种是某块网卡驱动在高负载下触发了空指针告警，本来只是丢一个包。
另外，kdump 没配好，连崩溃现场都没有留下。
先确认上次重启的原因
last -x reboot && journalctl -k -b -1 | tail -50然后查看内核参数与 kdump 状态
sysctl kernel.panic_on_oops kernel.panic && systemctl status kdump接着按业务容忍度决定是否保留该参数
sysctl -w kernel.panic_on_oops=0剩下的就是把决定写进配置并验证 kdump 可用
echo 'kernel.panic_on_oops = 0' > /etc/sysctl.d/90-panic.conf && sysctl --system怎么算真的好了，看的是同一批现象。vmcore-dmesg 里能看到完整调用栈并定位到具体驱动，机器不再因 WARNING 自动重启，业务连续运行超过一周没有意外重启记录。
这里还有个坑。这个参数适合必须保留现场的分析环境，生产上开了就等于把告警升级成宕机；关掉之前要确保日志和监控能捕获 oops。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。