定时任务失联需用crontab+flock+timeout三件套：flock防重叠执行，timeout控制时长并返回124码，失败时触发alarm.sh报警；同时显式声明path、重定向日志、确保脚本有执行权限并用env -i模拟crontab环境测试。
定时任务跑着跑着就失联了？不是没执行，就是卡住不动，或者多个实例同时跑把系统拖垮——这类问题在生产环境里太常见。光靠 crontab 本身远远不够，它只负责“按时喊一声”，不保证脚本是否真跑完、有没有卡死、会不会重复启动。要真正实现稳定、可监控、带报警的定时执行，得靠三件套配合：crontab 调度 + flock 互斥 + timeout 超时控制，再加一层轻量报警逻辑。
用 flock 防止任务重叠执行
脚本运行时间波动大，比如网络抖动导致某次耗时翻倍，下一轮 crontab 又准时触发，结果两个实例同时读写同一份数据——轻则结果错乱，重则数据库锁表。flock 就是来解决这个的。
- 给脚本加一层文件锁，用绝对路径的 .lock 文件（比如
/var/run/mytask.lock） - 推荐写法：
flock -n /var/run/mytask.lock -c 'bash /path/to/task.sh' -
-n表示非阻塞：如果锁已被占用，立刻退出，不等也不报错——crontab 自然就跳过这次执行 - 注意：lock 文件不会自动删除，但 flock 在进程退出后自动释放，无需手动清理
用 timeout 控制单次执行时长
有些脚本理论上几分钟能完，但偶发异常（如远端服务无响应、磁盘 IO 堵塞）可能卡十几分钟甚至更久。timeout 能主动掐断它，并返回明确状态码。
- 例如：
timeout -s TERM 300 bash /path/to/task.sh表示最多运行5分钟，超时就发 TERM 信号终止 - 超时后返回码是 124；正常结束是 0；被信号杀死（非 timeout）通常是 128+信号号
- 配合 shell 逻辑判断返回值，就能区分“成功”“超时”“崩溃”三种情况
超时后自动触发报警动作
光 kill 不够，得让人知道出事了。不需要接入复杂告警平台，一个简单脚本就能发邮件、写日志、甚至调用企业微信 webhook。
- 写个
alarm.sh：记录时间、写入/var/log/mytask-alarm.log，再用mail -s "Task Timeout" admin@example.com 发邮件 - 在 crontab 里这样串起来：
*/10 * * * * flock -n /var/run/mytask.lock -c 'timeout -s TERM 600 /path/to/task.sh || /path/to/alarm.sh' -
||表示前一条命令失败（返回非0）才执行 alarm.sh，正好覆盖超时和脚本内部报错两种场景
别忽略环境与日志细节
很多“任务不执行”问题其实和 crontab 本身无关，而是环境差异导致的静默失败。
- crontab 默认 PATH 很窄（通常只有 /usr/bin:/bin），脚本里用的命令（如 python3、jq）可能找不到——开头显式声明：
PATH=/usr/local/bin:/usr/bin:/bin - 所有输出重定向到日志：
>/var/log/mytask.log 2>&1，避免邮件堆积或信息丢失 - 脚本第一行必须是
#!/bin/bash，且确保有执行权限：chmod +x /path/to/task.sh - 测试时别只跑
./task.sh，要用env -i bash -c '/path/to/task.sh'模拟 crontab 环境
