每五分钟执行一次的脚本，偶尔需要十分钟才能跑完。下一次 cron 到点后仍然启动，两个进程同时操作同一批数据，日志交错，导出文件相互覆盖，接口也可能重复调用。
cron 按时间启动任务，通常不会替脚本判断上一轮有没有结束。固定调度间隔与实际耗时一旦交叉，就可能出现任务重叠。不过，重复业务结果也可能来自两条调度配置、应用重试或多台服务器，文件锁只能处理其中一部分。
本文适用于 Linux 上使用 util-linux flock 的单机任务。命令和路径均为示例，未在读者服务器上实测。涉及付款、消息发送和生产数据写入时，应先使用测试数据验证幂等性与恢复流程。
先区分重复配置和正常调度重叠
检查正在运行的进程、开始时间及父进程，判断是否存在多轮任务同时工作：
ps -eo user,pid,ppid,lstart,etime,args | grep '[r]un-report'
crontab -l
当前用户的 crontab -l 只显示该用户的任务。系统级 /etc/crontab、/etc/cron.d/、其他用户 crontab、systemd timer、面板任务和应用内部调度也需要按权限分别核对。
多节点部署时，还应确认是不是每台服务器都启用了相同任务。一个本地锁文件不会自动让另一台服务器停下来。
给任务日志补充运行标识、主机名、PID、开始和结束时间、退出状态，以及本轮处理的数据范围。避免记录密码、令牌和敏感业务明细。如果同一业务对象出现两次处理，应沿运行标识回溯，检查是两轮进程，还是同一轮内部重试。
在尚未确认影响时，不要批量 kill 掉所有匹配名称的进程。终止操作可能中断事务外的文件写入或远程调用，需要先明确当前阶段和恢复方法。
flock 锁的是打开的文件对象
flock 可以对文件施加建议性锁。使用同一个锁对象的参与者才会相互协调，不加锁的手动执行或另一段脚本仍然可能并发进入。
这种锁不依赖文件内容，也不是靠“文件存在”判断任务运行。锁的生命周期与打开的文件描述符有关：进程退出、相关描述符关闭后，锁才能释放；子进程继承描述符也可能延长持有时间。
因此，看到一个空锁文件，不代表任务卡住；把锁文件删除也不等于安全解锁。正在运行的任务可能仍锁着旧文件对象，新进程却创建并锁住另一个同名文件，结果两个任务同时运行。
正常使用中应保留稳定的锁文件路径。排查锁占用时，结合进程树、工具输出和任务日志判断，不靠删除文件恢复。
定时任务通常更适合拿不到锁就跳过
对于周期性刷新统计、同步快照等任务，如果下一轮可以覆盖本轮机会，非阻塞锁能避免积压：
/usr/bin/flock -n -E 75 /var/lib/report-job/run.lock \
/usr/local/bin/run-report
这里 -n 表示拿不到锁立即退出，-E 75 将锁冲突的退出码设为 75。75 是本例自选标记，应避开应用自己使用的状态码；如果应用也返回 75，仅看退出码就无法区分原因。
锁目录必须提前由管理员按最小权限创建，并确保调度用户可以打开锁文件。路径应位于可信、权限受控的目录，避免其他本地账户替换文件或插入符号链接。示例中的 /var/lib/report-job/ 不会由 flock 自动创建。
确认本机工具路径、用户权限和日志目录后，可以把下面一行放进该用户 crontab：
*/5 * * * * /usr/bin/flock -n -E 75 /var/lib/report-job/run.lock /usr/local/bin/run-report >> /var/log/report-job/run.log 2>&1
该示例每五分钟尝试启动一次，拿不到锁就跳过。日志文件也必须可写；shell 的重定向若先失败，flock 根本不会运行。系统 crontab 另有用户字段，不能不加区分地复制。
cron 的 PATH、工作目录和环境与交互终端不同。示例使用绝对路径，脚本内部仍需明确工作目录、配置文件和必要环境，避免把环境错误误判成锁失效。
什么时候才应该等待锁
flock -w 60 可以最多等待六十秒获取锁。它适合确实希望串行执行、且允许有限等待的场景，但等待会占用一个进程；调度频率高于处理能力时，积压仍可能增加。
/usr/bin/flock -w 60 -E 75 /var/lib/report-job/run.lock \
/usr/local/bin/run-report
六十秒只是示例。等待锁的超时与业务处理的超时是两回事，拿到锁以后，脚本仍然可能运行很久。
如果每次触发都必须保留，简单跳过会丢掉执行机会，等待又可能堆积。应考虑持久化队列、可恢复的任务记录或支持并发控制的调度器，并定义重试和消费规则。
超时需要与应用退出逻辑一起设计
长期运行的任务可能一直持有锁，让后续轮次持续跳过。除了告警，还可以在测试后为一次执行设定上限。使用 GNU coreutils timeout 的示例：
/usr/bin/flock -n -E 75 /var/lib/report-job/run.lock \
/usr/bin/timeout --signal=TERM --kill-after=30s 20m \
/usr/local/bin/run-report
这个组合在获得锁后启动 timeout；到二十分钟时请求终止，若仍未结束，再在三十秒后升级为强制终止。这些值没有通用推荐意义，需要结合业务耗时、退出处理和恢复能力决定。
脚本应以前台方式运行实际任务，避免自行后台化后让外层误以为已经完成。timeout 对进程组的处理、子进程逃逸或继承描述符的行为，也应在实际启动方式下验证。
默认情况下，发生超时时 timeout 通常返回 124，升级为 SIGKILL 等情形可能返回 137；其他错误还有不同状态。应参考本机版本手册，记录完整日志，不能仅凭一个状态码断言业务已安全回滚。
终止进程不会撤销已经发出的邮件、接口请求或提交的事务。写入型任务应支持检查点、原子替换或幂等标识。只有应用本身具备恢复边界，超时控制才不会把“任务太久”变成“数据处理到一半”。
多入口必须使用同一把锁
如果 cron 命令加了锁，但管理员习惯手动直接运行脚本，手动任务仍可能与定时任务重叠。可以把加锁逻辑集中到统一入口，让所有调用都经过它。
另一个常见错误是对同一任务使用不同锁路径，比如一处 /tmp/report.lock，另一处 /var/lock/report.lock。即使文件名相同，只要指向不同对象，就不能互斥。容器内路径相同，也可能属于不同文件系统或挂载命名空间。
如果决定在脚本内部加锁，要避免外层再对同一对象独立加锁，造成意外冲突或等待。选择一层负责锁管理，并把调用契约写清楚。
对于会派生后台子进程的任务，应明确谁持有描述符、何时退出。flock 的 --close 可用于避免命令继承锁描述符，但它也改变生命周期关系，不应在不了解进程结构时随意添加。
本地文件锁不能替代跨节点协调
多台服务器各自锁住本地文件，仍然可以同时执行任务。共享 NFS 或 SMB 的锁语义又受协议、内核、挂载选项和服务端支持影响，不能仅凭路径位于共享盘就认为具备可靠互斥。
跨节点场景通常需要调度单点、数据库协调或具备租约管理的分布式锁，并处理锁过期、续租失败和旧持有者继续运行的情况。重要写入还需要业务层防重或 fencing 等机制，避免锁失效后旧任务仍能提交结果。
把锁文件简单放进共享目录，不足以完成这些设计。应先确定故障模型，再选协调方案。
用受控并发验证，不拿生产写入做实验
在测试环境，用一个只写测试日志、可控等待的无副作用任务模拟长耗时，同时启动两个入口。确认第一轮持有锁时，第二轮按设计跳过或有限等待。
再测试第一轮正常结束、应用报错和收到终止信号之后，下一轮能否重新进入。检查是否有遗留子进程继续工作，以及日志是否能区分锁冲突、业务失败和超时。
生产验收还应观察一段代表性运行周期：是否持续跳过、耗时是否增长、有没有遗漏业务批次。锁能防止参与者同时执行，但不会自动解决处理能力不足。
最终应明确三件事：哪些入口共用锁、拿不到锁如何处理、执行中断后如何恢复。任务不会相互覆盖，失败记录也能追踪，才算完成这次修复。
参考资料
核验日期：2026-11-03。本文使用 Linux util-linux flock 与 GNU coreutils timeout 语义，其他系统或精简工具实现可能不同，请先检查本机帮助。