如何限制指定进程ops_tool仅单实例运行 禁止重复执行

ulimit属于用户/会话维度的全局资源限制，确实无法实现单个进程的单实例管控，以下是生产环境可直接落地的方案，按推荐优先级排序：

方案1：flock文件锁（优先选，无额外依赖、无竞态风险） #

这个方案是Linux环境下的通用最优解，util-linux组件内置的flock工具由内核维护锁状态，不存在进程异常退出锁残留、多进程并发判断穿透的问题：

• 提前创建固定路径的锁文件，给公共功能账号分配读写权限，例如/var/run/ops_tool.lock
• 将所有用户触发ops_tool的入口（包括软链接、别名、sudo授权的执行路径、定时任务配置）全部替换为flock包裹的启动命令：

# -n 为非阻塞模式，拿不到排他锁直接退出，不会等待现有进程结束
flock -n /var/run/ops_tool.lock -c "/opt/ops_tool/ops_tool $*"

• 不要自行实现「判断PID文件是否存在→写PID→启动进程」的逻辑，这类逻辑在多进程并发触发时会出现判断穿透，进程崩溃时还会残留无效PID导致后续进程无法启动。

方案2：cgroup pids控制器硬限制（系统层兜底，防绕过） #

如果需要防止用户绕开启动脚本直接执行原程序，可以用cgroup做内核级的硬限制，普通用户无权限修改cgroup配置，无法绕过：

• 基于cgroup v2创建专属限制组：mkdir /sys/fs/cgroup/ops_tool_single
• 设置组内最大进程数为1：echo 1 > /sys/fs/cgroup/ops_tool_single/pids.max
• 配置规则将公共账号启动的所有ops_tool进程自动加入该cgroup，组内进程数达到阈值时，内核会直接阻止新进程启动，返回资源不足错误。

方案3：程序内置锁（适合可修改源码的场景） #

如果持有ops_tool的源码维护权限，可以直接在程序启动入口最前端实现单实例锁逻辑：

• Linux环境直接调用flock系统调用申请固定路径的排他文件锁
• 锁申请失败直接打印错误日志、退出进程
  这种方案没有外层脚本的额外开销，逻辑最内聚。

避坑提醒：不要用ps aux | grep ops_tool | wc -l这类命令判断进程数做拦截，一方面存在并发判断穿透的竞态问题，另一方面会被同名进程、命令行参数包含ops_tool关键词的其他进程干扰，误拦截率极高。

内容的提问来源于stack exchange，提问作者anmoreira