获取服务器hung住时的崩溃日志并自动系统重启——监听服务器异常崩溃问题

问题回顾

你的服务器在 14:30-14:45 期间出现监控断点（机器hung住），你在 14:43:40 重启了机器。重启后恢复正常，但没有生成 vmcore 文件，所以无法进一步分析原因。

什么是 "hung住"？

Hung住 是指系统内核或进程卡死，无法响应：

无法执行任何命令
无法通过SSH连接
监控数据无法上报
只能通过硬重启恢复

一些配置的含义

1. 内核参数解释

bash 复制代码

# 提高看门狗阈值（默认10秒），避免误报
kernel.watchdog_thresh = 30

# 软锁定（soft lockup）时触发内核panic并重启
kernel.softlockup_panic = 1

# 启用看门狗（默认就是1）
kernel.watchdog = 1

# 当检测到进程hung（卡死）时触发panic
kernel.hung_task_panic = 1

# 启用SysRq魔法键（允许紧急操作）
kernel.sysrq = 1

# 内存耗尽（OOM）时触发panic而不是杀进程
vm.panic_on_oom = 1

2. hung task 机制原理

复制代码

内核线程 khungtaskd 每周期检查一次
    ↓
发现进程处于 TASK_UNINTERRUPTIBLE（D状态）超过 kernel.hung_task_timeout_secs（默认120秒）
    ↓
如果 hung_task_panic = 1 → 触发内核panic → 系统重启并生成vmcore
如果 hung_task_panic = 0 → 只打印堆栈信息，不重启

这段配置的作用

配置前（你目前的状态）

复制代码

系统hung住 → 没有vmcore → 无法分析原因 → 只能猜测

配置后

复制代码

系统hung住 → 自动触发panic重启 → 生成vmcore文件 → 分析根因 → 彻底解决

为什么要你加这些参数？

捕获问题现场 ：当系统再次hung住时，自动生成 vmcore 文件
分析根本原因：通过vmcore可以定位是哪个内核模块或驱动导致的问题
永久修复：找到根因后才能彻底解决，避免再次发生

如何配置

步骤1：添加参数

bash 复制代码

# 编辑系统控制文件
vim /etc/sysctl.conf

# 添加以下内容
kernel.watchdog_thresh = 30
kernel.softlockup_panic = 1
kernel.watchdog = 1
kernel.hung_task_panic = 1
kernel.sysrq = 1
vm.panic_on_oom = 1

步骤2：使参数生效

bash 复制代码

sysctl -p

步骤3：验证参数已生效

bash 复制代码

# 查看所有参数是否正确加载
sysctl kernel.watchdog_thresh kernel.softlockup_panic kernel.watchdog kernel.hung_task_panic kernel.sysrq vm.panic_on_oom

预期输出：

复制代码

kernel.watchdog_thresh = 30
kernel.softlockup_panic = 1
kernel.watchdog = 1
kernel.hung_task_panic = 1
kernel.sysrq = 1
vm.panic_on_oom = 1

配置后的影响

正常情况

系统正常运行，没有任何影响
只是增加了监控机制

再次hung住时

复制代码

系统检测到问题 → 自动panic → 生成vmcore → 系统重启（约1-2分钟）

潜在风险

可能触发误重启：如果某些正常的长耗时操作超过阈值，可能导致误判重启
解决方式 ：已经调高 watchdog_thresh 到30秒，降低误判概率

总结

项目	说明
问题	服务器曾hung住15分钟，需要重启恢复
原因	未知（可能内核bug、驱动问题、资源死锁）
解决方案	配置panic参数，下次hung住时自动生成vmcore
作用	捕获内核崩溃现场，供腾讯云分析根因
风险	极低（已调高阈值，减少误判）

建议按腾讯云的要求添加这些参数，这样下次再出现问题时就能找到根本原因并彻底修复。