Linux timeout命令：限制程序执行时间

timeout 命令看似简单，但实际使用时容易遇到问题。其核心机制涉及信号传递、进程组归属以及目标命令对信号的处理。直接执行 timeout 5s sleep 10 能够正常超时退出，但执行 timeout 5s bash -c "sleep 10" 时可能无法终止，原因是子进程逃逸和信号被忽略。

许多用户误以为超时失败是因为时间设置不当，实际上问题通常出在其他环节。下面分析几个典型问题。

为什么 timeout 后进程还在跑？

有时即使添加了 timeout 参数，通过 ps 命令仍会发现目标进程仍在运行。例如，执行 timeout 5s ping -c 10 google.com 后，ps aux | grep ping 可能显示残留进程。通常有三个原因：

• 子 shell 逃逸：使用 bash -c "..." 包装时，timeout 终止的是外层 bash，而实际执行命令的 ping 可能已经脱离原进程组，信号无法到达。
• SIGTERM 被忽略：许多程序（如 ffmpeg、自定义脚本）会主动捕获 SIGTERM 并执行清理操作，甚至直接忽略该信号，导致超时信号无效。
• 缺少终端上下文：在 cron 或 systemd 环境下执行时，如果命令依赖 TTY 才能启动，timeout 可能直接返回 127（命令未找到），看起来像未超时即结束，实际命令未运行。

怎么让 timeout 真正杀死目标进程？

解决思路不在于单纯延长超时时间，而在于确保信号能够正确传递并被目标进程处理。

• 加 --foreground：该参数阻止 timeout 创建新会话，避免子进程脱离控制组。例如 timeout --foreground 5s bash -c "sleep 10" 可使信号沿进程组逐级传递。
• 使用 -k 选项：先发送 SIGTERM 警告，若目标进程未及时退出，则在一定时间后发送 SIGKILL 强制终止。例如 timeout -k 2s 5s long_command，5 秒后发 SIGTERM，2 秒内未退出则执行 SIGKILL。
• 更换信号类型：部分程序对特定信号（如 SIGUSR1）有优雅退出处理，可尝试 timeout -s USR1 5s ./myapp。
• 确认进程归属：可通过 pgrep -P $(pgrep -f "timeout.*long_command") 检查子进程是否仍在原进程组内。

如何在脚本中正确判断超时？

常见错误是使用 if timeout 3s cmd; then 的形式进行判断。由于超时返回码为 124（非零），if 语句会进入 else 分支，导致无法区分是超时还是命令执行失败（例如权限不足返回 1）。

• 必须显式检查 $：正确写法如下：

timeout 3s some_command
case $ in
  0)     echo "success";;
  124)  echo "timed out";;
  127)  echo "command not found";;
  *)    echo "other error: $" ;;
esac

• 避免 && 链式调用：超时会导致整条链直接中断，且无任何提示，增加调试难度。
• 封装成函数更稳妥：例如：

run_with_timeout() {
  timeout "$1" "${@:2}"
  return $
}
run_with_timeout 5s curl -s http://example.com && echo "ok"

调用后立即检查 $，逻辑更清晰。

不同场景下的单位与兼容性注意点

时间格式看似宽松，实际存在细节差异：

• 小数支持有限：0.5s 在多数系统下可用，但 0.1s 在旧版 coreutils（如 CentOS 7 默认版本）中可能被截断为 0，相当于未设置超时，命令将无限运行。
• 单位省略有风险：直接写 timeout 5 cmd 虽简洁，但若环境变量 TIMEOUT 被污染（某些容器镜像曾出现此情况），行为可能被意外覆盖。
• 跨平台差异大：macOS 不自带 timeout，需通过 brew install coreutils 安装后使用 gtimeout；Alpine Linux 默认使用 busybox timeout，不支持 -k 和 --preserve-status。
• --preserve-status 的误解：该选项仅使 timeout 返回被终止命令的原退出码（例如命令自身 exit 1，timeout 也返回 1），但超时事实并未改变——仍需检查 124 才能确认是否因超时导致。

最后需注意：超时并非精确计时器。Linux 调度延迟、信号投递抖动以及进程清理开销，都会使实际终止时间比设定值多出几十到几百毫秒。如需亚秒级强实时控制，timeout 不是合适工具，应使用应用层心跳或专用监控进程。