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，任务卡住后所有后续调度都会挂起等待，比重复执行还难排查。
