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 不是合适的工具，应该考虑应用层心跳或者专用的监控进程。