Linux 定时任务重复执行的防范方案

crontab任务重复执行是因默认不检查进程状态，到点即fork新进程；用flock加锁最稳妥，需绝对路径、可写权限，并推荐加-n非阻塞标志防堆积。

crontab 任务重复执行的典型现象

当 crontab 中的任务运行时间短、但实际耗时长（比如脚本卡在 http 请求或数据库锁上），下一次调度可能在前一次还没退出时就启动，导致并发执行。常见表现包括：日志里出现双倍记录、数据库写入冲突、临时文件被覆盖、磁盘空间突增。

这不是 crontab 的 bug，而是它默认不检查进程状态——只要到点就 fork 新进程。

用 flock 防止并发执行最稳妥

flock 是 linux 自带的文件锁工具，轻量、可靠、无需额外依赖，适合绝大多数场景。

• 它对同一文件加锁，多个进程竞争同一个锁文件，只有一个能拿到并继续执行
• 锁自动释放（进程退出或崩溃时内核回收），不会死锁
• 必须用绝对路径，且锁文件需有可写权限（推荐放在 /tmp 或脚本同目录）

示例：把原来 */5 * * * * /home/user/backup.sh 改成：

*/5 * * * * flock -n /tmp/backup.lock -c '/home/user/backup.sh'

-n 表示非阻塞，拿不到锁直接退出，避免堆积；如果希望排队等锁，改用 -w 30（最多等 30 秒）。

脚本内自检 PID 文件的适用边界

在脚本开头手动检查 /var/run/myscript.pid 是否存在、对应进程是否存活，是老派做法，但容易出错。

• 进程意外崩溃后 .pid 文件残留，会导致后续任务永远跳过
• ps 解析不稳定（不同系统输出格式不同），pgrep -f 又可能误匹配其他进程
• 需要额外处理信号（如 SIGHUP）来清理 PID 文件，否则不可靠

仅建议用于无法使用 flock 的极少数环境（比如某些容器里没装 util-linux），且必须配合超时判断和清理逻辑。

systemd timer 替代 crontab 的注意事项

如果系统已启用 systemd，用 OnCalendar + StartLimitIntervalSec 能更精细地控制并发，但要注意：

• StartLimitIntervalSec 和 StartLimitBurst 控制的是“启动频率”，不是“运行互斥”——仍需在 service 单元中加 flock 或 Type=oneshot + RemainAfterExit=yes 配合状态检查
• RandomizedDelaySec 会打乱定时精度，不适合强时效性任务
• systemd 日志默认走 journald，排查时得用 journalctl -u mytask.service，别只盯 /var/log/syslog

真正省心的方案，还是回到 flock：它不挑 init 系统，不依赖服务管理器，一行命令就能堵住并发口子。最容易被忽略的是锁文件路径权限和 -n 标志的必要性——没加 -n，任务卡住后所有后续调度都会挂起等待，比重复执行还难排查。