Linux怎么使用timeout命令限制执行时间
Linux中timeout命令需注意子进程逃逸与信号忽略问题，可通过--foreground参数或加-k强制SIGKILL解决。超时返回码为124，应显式检查$?区分超时与命令错误。时间格式、跨平台差异及亚秒级实时限制也需留意。
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 不是合适的工具，应该考虑应用层心跳或者专用的监控进程。
