kernel.panic必须设为非零值（如60）才启用自动重启，否则默认卡死；需配合panic_on_oops=1、softlockup_panic=1及kdump捕获vmcore，再通过echo c > /proc/sysrq-trigger验证全流程。

kernel.panic 参数必须设为非零值才生效

内核 Panic 后默认卡死，不会自动重启。关键就一个参数：kernel.panic，它的值决定等待多少秒后硬复位。设为 0（默认）等于禁用自愈；设为正整数（如 60）才真正触发重启。

临时生效（重启即失效）：
sudo sysctl -w kernel.panic=60

永久生效：
echo "kernel.panic = 60" | sudo tee -a /etc/sysctl.d/99-panic.conf
sudo sysctl --system

验证是否写入成功：
cat /proc/sys/kernel/panic 应输出 60

注意：这个重启是内核直接调用 emergency_restart()，不经过 systemd、不执行 shutdown 脚本、不 sync 磁盘——它就是“拔电源式”恢复，快但粗暴。

panic_on_oops 和 softlockup_panic 必须显式启用

很多故障不是直接 panic，而是先出现 oops 或软锁死（soft lockup），系统表面还在运行，实则已不可信。生产环境必须把它们也纳入自愈范围。

检查当前状态：
cat /proc/sys/kernel/panic_on_oops（应为 1）
cat /proc/sys/kernel/softlockup_panic（默认常为 0）

Alpine Linux

获取最新发布版本；聚合最新版本架构

下载

启用方式：
echo 1 | sudo tee /proc/sys/kernel/panic_on_oops
echo 1 | sudo tee /proc/sys/kernel/softlockup_panic
echo 1 | sudo tee /proc/sys/kernel/hung_task_panic

写入配置文件（避免重启丢失）：
echo "kernel.panic_on_oops = 1" | sudo tee -a /etc/sysctl.d/99-panic.conf
echo "kernel.softlockup_panic = 1" | sudo tee -a /etc/sysctl.d/99-panic.conf

不启用 panic_on_oops，某些驱动错误只会打印 Oops 日志，然后系统继续跑着，但内存可能已损坏；不启用 softlockup_panic，CPU 被单一线程霸占几分钟也不会触发重启，用户请求全卡住却无任何告警。

kdump 不只是可选项，而是自愈闭环的必要一环

只设 kernel.panic 等于“救活人但烧掉病历”。重启会清空 RAM，没有 vmcore 就无法定位根因。kdump 是唯一标准方案，它靠预留内存加载第二个内核来捕获现场。

三步缺一不可：
- 在 GRUB 启动参数中加 crashkernel=512M（根据物理内存选值），再运行 sudo update-grub 并重启
- 安装并启用服务：sudo apt install linux-crashdump（Ubuntu）或 sudo yum install kexec-tools（RHEL），然后 sudo systemctl enable --now kdump
- 验证是否就绪：sudo kdumpctl status 输出 ready，且 ls /sys/kernel/kexec_crash_loaded 返回 1

关键细节：
- crashkernel=auto 在某些旧内核上不可靠，建议显式指定大小
- /var/crash 分区空间必须 ≥1.5× 物理内存，否则转储失败且不报错
- 默认不压缩 vmcore，大内存机器转储耗时极长，应在 /etc/kdump.conf 中启用：core_collector makedumpfile -l -d 31

验证必须用 echo c > /proc/sysrq-trigger，别等真崩溃

手动触发可控 panic 是唯一可靠验证方式。但前提是 sysrq 已启用，否则命令无效。

启用 SysRq：
echo 1 | sudo tee /proc/sys/kernel/sysrq
持久化：echo "kernel.sysrq = 1" | sudo tee -a /etc/sysctl.d/99-sysrq.conf

触发测试：
echo c | sudo tee /proc/sysrq-trigger

观察行为：
- 屏幕立即刷出 Kernel panic - not syncing 日志
- 停顿约 kernel.panic 设定的秒数（如 60 秒）
- 自动重启，且重启后 ls /var/crash/ 应见时间戳目录和 vmcore-dmesg.txt

最容易忽略的一点：测试前没确认 kdump 是否 active，导致 panic 后只重启、没生成 vmcore，误以为配置成功。实际是“半自愈”——止血了，但没留病历。