我之前也碰到过一模一样的情况！当你用scancel干掉被依赖的任务后，Slurm会直接把依赖任务的状态锁死在DependencyNeverSatisfied——哪怕你用scontrol requeue重启了原任务，Slurm也不会主动去重新检查依赖条件，因为它已经记下了原任务被取消的“历史记录”。

要搞定这个，你得手动给依赖任务重置依赖规则，具体操作很简单：

一步一步来操作（对应你的示例） #

假设你的原任务ID是1，依赖它的任务是89：

1. 先确认重入后的原任务已经正常跑起来了：

   squeue -j 1
   

   看到它处于R状态就没问题。

2. 然后用scontrol update命令给依赖任务重新绑定依赖：

   scontrol update JobId=89 Dependency=aftercorr:1
   

   这里的aftercorr:1要和你最开始提交依赖任务时用的规则一致，要是你用的是afterok或者其他类型，直接替换就行。

3. 再查一下队列状态：

   squeue -j 89
   

   这时候依赖任务应该会从DependencyNeverSatisfied变回Dependency状态，等原任务跑完就会自动启动了。

为啥会出现这个坑？ #

Slurm的依赖判断是认任务的最终状态的：当你scancel任务1时，Slurm给它打了个CANCELLED的标签，依赖任务89的条件就直接被判为“永远满足不了”，而且这个标记是不会自动解除的。哪怕你requeue让任务1复活，Slurm也不会回头去更新依赖任务的状态，必须手动重置规则才行。

给你提个预防小建议 #

如果你的流水线经常需要处理任务崩溃重入的情况，不如试试这两个优化：

• 提交依赖任务时用afterany替代aftercorr/afterok，这样不管原任务是正常完成还是重入后完成，依赖任务都会触发（当然得看你的实际需求哈）。
• 提交任务时加上--requeue参数：sbatch --requeue run.sh，让Slurm在任务崩溃时自动帮你重入，省得手动scancel再requeue，也就不会触发这个依赖锁死的问题了。

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