hangcheck-timer异常会导致节点意外重启或CSS反复驱逐，需通过dmesg日志、模块加载状态及参数（hangcheck_tick+hangcheck_margin＜CSS misscount）综合定位。
hangcheck-timer 异常不会直接报错，但会导致节点被意外重启或 CSS 进程反复 evict，必须从内核日志和模块参数入手定位。
确认 hangcheck-timer 是否已加载且参数生效
模块未加载、参数未传入或被覆盖是常见起点。Linux 2.6+ 内核默认不自动加载该模块，也不能靠 /etc/modprobe.conf 静态配置（该文件在较新系统中已被废弃）。
- 检查是否加载：
lsmod | grep hangcheck_timer—— 注意模块名含下划线，不是hangcheck-timer - 查看当前运行参数：
cat /sys/module/hangcheck_timer/parameters/* 2>/dev/null，重点确认hangcheck_tick、hangcheck_margin、hangcheck_reboot的值 - 若参数全为 0 或未显示，说明模块虽加载但未传参；若根本没输出，说明模块未加载
- 手动加载并传参示例：
modprobe hangcheck_timer hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1（注意：此操作不持久，需写入/etc/sysconfig/modules/或 systemd 模块加载服务）
从 dmesg 日志中识别 hangcheck 触发事件
hangcheck-timer 在触发动作时会向内核 ring buffer 写入明确标记，不依赖 Oracle 日志。错过这条线索就等于放弃最直接证据。
- 执行：
dmesg -T | grep -i "hangcheck\|reboot\|fence"，重点关注带时间戳的输出 - 典型正常触发日志：
[Sun Sep 28 12:45:22 2026] hangcheck: hangcheck value past margin! - 典型重启日志：
[Sun Sep 28 12:45:22 2026] hangcheck: starting hangcheck timer (tick is 1 second, margin is 10 seconds)后紧跟Kernel panic - not syncing: Hangcheck timer: hangcheck value past margin! - 若看到
hangcheck: lost ticks，说明系统调度严重延迟（如 CPU 耗尽、中断被屏蔽、VM 停顿），不是模块本身问题，而是底层资源瓶颈
验证与 CSS misscount 的数值匹配关系
Oracle CSS 层的 misscount 必须严格大于 hangcheck_tick + hangcheck_margin，否则 hangcheck 会在 CSS 做出判断前就强制 reboot，造成“抢跑式驱逐”。
- 查当前 misscount：
crsctl get css misscount（需以 grid 用户执行） - 计算安全阈值：例如
misscount=30，则hangcheck_tick + hangcheck_margin必须 ≤ 29；若设为 30，则任意一次 tick 延迟 ≥1 秒就会触发 reboot - 常见错误配置：
misscount=30却配了hangcheck_tick=1 hangcheck_margin=30→ 总和 31 > 30 → hangcheck 总比 CSS 先动手 - 11g RAC 推荐组合（非绝对，但经验证稳定）：
misscount=30对应hangcheck_tick=1 hangcheck_margin=10；misscount=220（旧部署）对应hangcheck_tick=30 hangcheck_margin=180
区分 hangcheck-reboot 和 oprocd 行为差异
11g 中 oprocd 已被弃用（仅保留在 10.2.0.4+ 的兼容模式），但部分老环境或误配置仍可能共存，两者触发条件和日志位置完全不同，混查会误导判断。
-
oprocd日志在：/var/opt/oracle/oprocd/或/etc/oracle/oprocd/下的oprocd.log，含"time regression"、"timeout exceeded"等关键词 -
hangcheck_timer日志只在dmesg，不出现在任何用户空间日志文件中 - 进程层面：
ps -ef | grep oprocd若有结果，说明环境存在冗余或降级配置，应停用并清理；而lsmod | grep hangcheck才是 11g RAC 的正统机制 - 关键区别：oprocd 可因系统时间回拨（Bug 5015469）误触发；hangcheck_timer 依赖 TSC，不受 NTP 时间跳变影响，但对 TSC 不稳的虚拟化环境更敏感
真正难排查的 case 往往不是参数写错，而是 hangcheck_tick + hangcheck_margin 刚好卡在 misscount 边界上，加上系统偶发调度抖动，导致 reboot 间隔飘忽不定 —— 这时候必须同时抓 dmesg -w 实时流和 crsctl get css boottime 对照节点重启时间戳，才能确认是 hangcheck 主动出手，还是 CSS 正常驱逐后节点自愈失败。
