Slurm集群环境下Snakemake作业是否会意外同时重复运行？

这种两个作业同时写入同一输出文件的情况会实际发生，不存在天然的机制阻断。
中断本地Snakemake主进程时，Slurm侧的作业调度是完全独立的：主进程退出不会自动联动终止已经提交到Slurm队列的作业，这些已经提交的作业会正常排队、执行、按流程写输出文件。如果中断后立刻重启Snakemake，新的主进程对游离在集群上的旧作业没有状态感知，只要对应路径下还没有出现完整的输出文件，就会判定该作业需要重新提交，直接产生同目标路径的并行写入冲突，轻则导致输出文件损坏、校验失败，重则造成集群存储的权限异常。

Snakemake本身设计了完整的状态追踪逻辑，但这套逻辑的覆盖范围有明确前提：

• 常规正常运行时，Snakemake不需要额外的中心化状态库，会基于输出文件存在性、文件校验和、输入输出时间戳的依赖关系判定作业的完成状态。运行过程中会把已提交作业的Slurm作业ID、临时运行文件存在项目路径下的.snakemake隐藏目录中，正常优雅退出时这些记录会被保留。
• 当流程因单个作业失败触发自动终止时，Snakemake会主动向Slurm发送取消指令，把所有已提交、尚未完成的关联作业全部终止，不会留下游离作业。
• 这套状态追踪机制仅在主进程正常持有作业会话连接时生效：当你通过Ctrl+C强制中断主进程时，Snakemake的清理动作有明确的触发阶段——单次按Ctrl+C会触发优雅退出流程，主动完成集群作业清理；如果连续按两次（或者手动直接杀掉主进程），这套清理逻辑会被中断执行，之前提交到集群的作业会完全脱离Snakemake的状态追踪范围，新启动的主进程无法识别这些已经在跑的旧作业，对应的作业状态记录也会失去同步。

• 触发中断时尽量只按一次Ctrl+C，耐心等待Snakemake完成优雅退出流程，不要连续强杀进程。这套优雅退出流程会自动清理所有已提交的Slurm作业，从根源上避免游离作业残留。
• 如果已经强杀了主进程，重启流程前一定要手动核查集群状态：通过squeue -u 你的用户名 查询当前账号下所有在排队、运行中的Slurm作业，把属于旧Snakemake流程的作业用scancel 作业编号 全部终止，确认没有残留作业后再启动新的运行实例。
• 重启Snakemake时可以搭配--rerun-incomplete参数，让Snakemake主动识别所有上次运行未生成完整输出的作业，直接标记为需要重跑，避免因为残留临时文件误判作业状态。
• 长期在Slurm环境跑流程的场景，可以配置--cluster-status 同步脚本，让Snakemake在启动时主动查询Slurm集群上关联作业的运行状态，对仍在运行的作业自动等待，不会重复提交，从机制上杜绝重复写入的风险。

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