直接用timeout包裹调用最简可靠，但必须用-k强制杀招和--foreground防逃逸，显式判断退出码124区分超时与失败，并在cron/systemd中补全path及绝对路径，管道需整体包裹。
直接用 timeout 包裹脚本调用是最简、最可靠的方案，但必须避开默认行为的坑——不是加个时间参数就能稳控进程。
关键参数组合：-k + --foreground 缺一不可
不稳定巡检脚本（如调用老旧 CLI 工具、频繁 fork 子进程、卡在系统调用）常会逃逸 timeout 控制。原因包括：
- 默认不发 SIGKILL，只发 SIGTERM，而脚本或其子进程可能忽略该信号
- 脚本内部启动新会话（如 ssh、docker run、sudo -i），脱离 timeout 的进程组
正确写法示例：
timeout --foreground -k 3s 120s ./health-check.sh --mode=full
-
--foreground：让脚本继承当前终端会话，确保所有子进程都在同一进程组内受管 -
-k 3s：超时后先发 SIGTERM，3 秒内未退出则立刻发 SIGKILL 强杀，堵死“假死”漏洞 -
120s：挂钟时间上限，适用于网络等待、I/O 阻塞等真实耗时场景
退出码必须显式判断，不能依赖 && 或 if 简单分支
timeout 超时返回 124，脚本自身失败可能返回 1、2、127 等。混用会导致误判——比如把超时当成成功跳过告警。
推荐结构：
timeout --foreground -k 2s 90s ./check-disk.sh<br>case $? in<br> 0) echo "OK";;<br> 124) echo "ALERT:巡检超时，强制终止" >&2; exit 1;;<br> 127) echo "ERROR:脚本缺失或无执行权限" >&2; exit 1;;<br> *) echo "FAIL:非超时错误，退出码 $?" >&2; exit 1;;<br>esac
在 cron 或 systemd 中运行要补全环境链
交互终端能跑通，放到后台常静默失败，主因是：
- cron 默认 PATH 极简（通常只有 /usr/bin:/bin），找不到 timeout 或被调脚本
- systemd 不分配 TTY，某些巡检命令（如含 ssh -o StrictHostKeyChecking=no）会因缺少 stdin 或 TERM 变量失败
对应处理：
- cron 任务中全部使用绝对路径：
/usr/bin/timeout --foreground -k 5s 180s /opt/scripts/cluster-scan.sh - systemd service 文件中显式声明：
Environment=PATH=/usr/local/bin:/usr/bin:/bin<br>StandardOutput=journal<br>StandardError=journal
管道与复合命令必须整体包裹
巡检脚本常需解析输出、过滤结果或写入日志。若只给首命令加 timeout，后续环节仍会继续执行：
- ❌ 错误：
timeout 60s cat status.json | jq '.health' | grep OK→ 只杀 cat，jq 和 grep 照常跑 - ✅ 正确：
timeout --foreground -k 3s 60s sh -c 'cat status.json | jq ".health" | grep OK > /tmp/health.ok 2>/dev/null'
本质是把整个 pipeline 当作一个原子操作交由 timeout 管控，避免逻辑断裂。
