Linux flock 如何保护一次性任务：文件锁、退出码与异常释放

凌晨补跑数据同步时，最怕的不是命令失败，而是同一份任务已经在后台运行，又被第二次启动。Linux 的 flock 可以把互斥关系交给内核维护：拿到锁的进程继续执行，拿不到锁的进程立即退出，进程结束后锁也随之释放。

一次性任务应让锁跟着执行进程走，并明确区分“成功拿锁”和“已有实例”两个退出结果；不要只创建一个锁文件就把它当成互斥机制。

先把“重复启动”变成可观察的信号

先准备一个不会被清理脚本误删的锁文件路径，例如 /run/lock/report-sync.lock。锁文件本身可以是空文件，真正的互斥来自内核持有的文件描述符，而不是文件是否存在。

#!/usr/bin/env bash
set -u

LOCK_FILE=/run/lock/report-sync.lock
flock -n "$LOCK_FILE" -c 'echo "lock acquired"; ./sync-report.sh'
status=$?

case "$status" in
  0) echo "sync finished" ;;
  1) echo "another sync is running" >&2 ;;
  *) echo "sync failed: exit=$status" >&2 ;;
esac
exit "$status"

这里的关键节点是 flock -n、LOCK_FILE 和 sync-report.sh：前者尝试获取锁，中间值指向同一锁对象，后者只有拿锁成功才会运行。实际环境中如果锁目录需要权限，应先让运行用户能创建或打开该路径。

用非阻塞模式决定是否排队

flock -n 的含义是拿不到锁就立刻返回。对 cron、systemd timer 或人工补跑来说，这通常比无限等待更安全：第二个实例不会悄悄积压，也不会在几个小时后突然同时执行。

flock -n /run/lock/report-sync.lock -c './sync-report.sh'
case "$?" in
  0) echo "completed" ;;
  1) echo "skipped: lock is busy" ;;
  *) echo "failed: inspect sync-report.sh" >&2 ;;
esac

上线前手工启动一个较慢的测试实例，再从另一个终端执行同一命令。第二次执行应快速返回，并出现 skipped: lock is busy；如果第二次命令一直等待，说明实际调用路径没有使用非阻塞模式。

退出码要和业务失败分开处理

不要把所有非零退出都写成“任务失败”。脚本本身失败、命令不存在、权限不足，与“已有实例正在运行”是三种不同信号。若监控只关心任务是否真正执行，可以把锁忙单独映射成跳过；若要求每次触发都必须成功，则应让调度系统记录锁忙并安排人工确认。

还要注意 flock -c 会把命令的退出结果传回调用方。这样可以保留 sync-report.sh 的真实失败码，而不是因为锁包装器存在就丢失错误位置。

异常退出时为什么不需要手工删锁文件

锁由打开的文件描述符维持。持锁进程正常退出、被信号终止，或执行中的子命令失败后结束，内核都会释放这次锁占用；留下的 /run/lock/report-sync.lock 只是路径，不代表仍有进程持有锁。

因此不要在失败处理里无条件执行 rm -f /run/lock/report-sync.lock。如果旧实例还活着，删除路径并不会解除它的文件锁，反而会让下一次启动打开一个新路径，形成两个看似相同的锁对象。

一套可以回滚的验收步骤

1. 确认运行用户能访问 /run/lock，并把实际锁路径固定为 LOCK_FILE。
2. 启动一个可观察的 sync-report.sh，确认日志出现 lock acquired。
3. 在另一个终端再次执行 flock -n，确认快速返回 skipped: lock is busy。
4. 结束第一个实例后再次执行，确认能够重新拿到锁。
5. 故意让 sync-report.sh 返回非零，确认包装脚本保留真实失败码，并检查监控映射。

常见问题与延伸问答

锁文件存在是不是说明任务还在运行？

不是。路径可能一直存在，只有文件描述符仍被进程持有时才代表锁忙。

为什么不用 mkdir 做锁？

mkdir 可以实现简单占位，但异常清理、锁归属和误删处理更容易靠脚本维护；flock 把持有关系交给内核，通常更适合单机任务。

应该用阻塞 flock 让任务排队吗？

如果任务必须按顺序执行可以排队，但定时补跑通常更需要快速暴露重复触发，所以应明确使用 -n 并记录跳过原因。

总结

可靠的一次性任务不是“创建一个 lock 文件”，而是让 flock -n、LOCK_FILE 与 sync-report.sh 形成清晰的进程调用链，再把锁忙、业务失败和成功分别记录。验收时同时测试重复启动、正常释放和异常退出，才能确认这层保护真的覆盖了补跑场景。