timeout命令在crontab定时任务中的使用：3个实战技巧让定时任务不再失控

为什么要在 crontab 定时任务里加 timeout

定时任务最怕的不是报错，而是“卡死”。备份脚本、数据同步、远程 API 拉取这类任务，一旦遇到网络抖动或下游无响应，很可能一挂就是几个小时。更糟的是，cron 不管你上次跑没跑完，到点又拉起一个，进程层层叠加，CPU、内存、数据库连接数很快被打爆。给 crontab 任务套一层 timeout 超时控制，是成本最低、见效最快的解法——它本来就是 coreutils 自带的，绝大多数 Linux 发行版开箱即用，几乎零依赖。

技巧一：直接包裹命令，简单粗暴

最基础的用法，就是把原来的命令用 timeout 包起来，指定一个时长，时间一到默认发送 SIGTERM(15) 让程序优雅退出。

# 每天 2:30 执行备份，最多跑 30 分钟，超时自动终止
30 2 * * * timeout 30m /opt/backup.sh

• 时长支持 s/m/h/d 后缀，“30m” 比手写 “1800” 秒直观得多，也更好维护。
• 超时后 timeout 默认发 SIGTERM，给程序清理临时文件、关闭连接的机会，比直接强杀温柔。
• 退出码 124 表示“任务被超时杀掉”，在脚本里用 if [ $? -eq 124 ] 就能针对性处理。

技巧二：配合 -s 和 --kill-after 双保险

有些程序会忽略 SIGTERM——死循环、卡在不可中断睡眠（D 状态）的进程，光靠默认信号根本杀不掉。这时候要把“第一次信号”和“兜底强杀”分开配置。

# 先发 SIGTERM，若 10 秒后还没退出，就发 SIGKILL 强杀
30 2 * * * timeout -s SIGTERM --kill-after=10s 30m /opt/backup.sh

• -s 指定的是“第一次”发送的信号，可以换成 SIGINT、SIGHUP 等自定义信号。
• --kill-after 才是真正的兜底：第一次信号没生效时，补一发 SIGKILL。
• 注意：个别进程（如卡在内核 IO 的 D 状态）连 SIGKILL 都杀不掉，那是底层存储或驱动的问题，得从系统层面排查，不是 timeout 能解决的。

技巧三：flock + timeout 防重复堆积

光限制单次超时还不够。如果任务本就跑得慢，下次到点又启动，还是会叠出一堆“幽灵进程”。把文件锁 flock 和 timeout 叠起来，才是完整方案。

# 拿不到锁就直接跳过（防重叠），同时限制单次最多跑 2 小时
*/10 * * * * flock -n /tmp/sync.lock timeout 2h /opt/sync.sh

• flock -n：上锁失败立即返回，避免同一任务反复叠加。
• timeout：兜底单次执行时长，双保险互不冲突。
• 可以再叠加退出码判断做告警：124 代表超时、1 代表 flock 抢锁失败，分工明确。

三个最容易踩的坑

• crontab 的 PATH 极简：默认只有 /usr/bin:/bin，脚本里务必写绝对路径，或在脚本开头 source 环境变量。
• 退出码别搞混：0 是正常完成，124 才是被超时杀掉；判断超时必须用 124 而不是笼统的非零。
• 别忘了重定向输出：不重定向的话，cron 会把每个任务的 stdout/stderr 发邮件，时间久了 /var/spool/mail 会被塞爆，建议统一追加 >> /var/log/xxx.log 2>&1。

小结

把 timeout 塞进 crontab，本质上是给失控的定时任务装了个“熔断开关”：单条命令包一层解决超时，加 -s/--kill-after 解决顽固进程，再叠 flock 防止堆积。三招下来，定时任务基本就翻不了车了。想进一步吃透 timeout 的信号与退出码机制，下面几篇可以顺着读。

相关阅读：timeout --kill-after二次信号发送机制详解、timeout --preserve-status保留原退出码用法、timeout -s参数发送自定义信号实战用法。