生产环境需实现内核崩溃自动重启、现场保留与服务兜底三层联动：设kernel.panic=60、panic_on_oops=1等参数启用自愈；配套kdump保存vmcore；systemd配置Restart=on-failure防雪崩；物理服务器启用硬件watchdog作为最后防线。
生产环境需要的是“故障发生时系统自己动起来”，而不是等人工半夜爬起来敲命令。内核崩溃（panic/oops）本身不可完全避免，但响应方式可以做到全自动、可追溯、低损伤。核心思路是三层联动：快速重启止损 + 完整现场保留 + 服务级兜底恢复。
一、让内核崩溃后立即自动重启
关键参数写入 /proc/sys/kernel/，并持久化到 /etc/sysctl.conf：
- kernel.panic = 60：崩溃后等待60秒再重启。设为0表示不自动重启；设为正数才启用自愈。60秒足够让kdump捕获vmcore，又不至于长时间停机
- kernel.panic_on_oops = 1：把oops也当作panic处理。生产环境不允许“带伤运行”，避免掩盖更深层问题
- kernel.softlockup_panic = 1：软锁死（如CPU被单一线程长期独占）直接触发panic。这是大促期间数据库服务器卡死的常见原因
- kernel.hung_task_panic = 1：僵死任务（如D状态进程持续超120秒）升级为panic。防止I/O卡死拖垮整机
执行生效：
echo 60 > /proc/sys/kernel/panic
echo 1 > /proc/sys/kernel/panic_on_oops
sysctl -p
二、必须配套kdump保存崩溃现场
自动重启只是“止血”，没有vmcore就等于没黑匣子，下次还会踩坑。kdump不是可选项，是生产标配：
- 预留内存（如crashkernel=512M）需在GRUB启动参数中静态配置，不能靠运行时调整
- 确保kdump服务已启用：systemctl enable --now kdump，并验证systemctl status kdump为active
- 转储目标建议设为远程NFS或本地LVM逻辑卷，避免/var/crash写满根分区
- vmcore生成后自动压缩（通过/etc/kdump.conf中core_collector makedumpfile -c --message-level 1 -d 31）
测试是否生效：echo c > /proc/sysrq-trigger（触发panic），观察/var/crash下是否生成时间戳目录和vmcore-dmesg.txt。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
三、systemd服务层加第二道保险
内核没崩，但关键服务（如nginx、redis、java应用）反复崩溃怎么办？靠systemd自身机制兜底：
- 在服务unit文件[Service]段添加：
Restart=on-failure
RestartSec=3
StartLimitIntervalSec=60
StartLimitBurst=3 - 解释：仅非正常退出才重启；每次间隔3秒；60秒内最多重启3次，超限后进入start-limit-hit状态，强制人工介入——防雪崩，不放任循环失败
- 对有状态服务（如MySQL），慎用Restart=always，避免数据损坏后反复拉起
配置后务必执行：systemctl daemon-reload && systemctl restart 服务名。
四、Watchdog硬件级兜底（推荐物理服务器启用）
当内核彻底卡死（连SysRq都无响应）、kdump无法触发时，硬件看门狗是最后一道防线：
- 确认主板支持（lspci | grep -i watchdog），加载驱动：modprobe i6300esb（Intel）或modprobe w83627hf_wdt（Winbond）
- 安装watchdog服务：apt install watchdog（Debian/Ubuntu）或yum install watchdog（CentOS/RHEL）
- 配置/etc/watchdog.conf启用watchdog-device = /dev/watchdog，并取消注释max-load-1 = 24等基础检测项
- 启动服务：systemctl enable --now watchdog。它会每10秒“喂狗”，超时即硬重启
注意：云主机通常不提供硬件看门狗，此时应依赖云平台的实例健康检查+自动重建策略。
