问为什么Slurm会在几秒钟后杀死一个特定用户的作业？

EN

我管理一个由许多用户组成的Slurm集群，集群的操作对于所有用户来说都是“完全正常”的；除了一个用户。这个用户可以在20-25秒后通过Slurm执行命令。

下面的最小示例再现错误：

$ sudo -u <the_user> srun --pty sleep 25
srun: job 110962 queued and waiting for resources
srun: job 110962 has been allocated resources
srun: Force Terminated job 110962
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP 110962.0 ON <node> CANCELLED AT 2021-04-09T16:33:35 ***
srun: error: <node>: task 0: Terminated

当发生这种情况时，我会在slurmctld日志中找到这一行：

_slurm_rpc_kill_job: REQUEST_KILL_JOB JobId=110962 uid <the_users_uid>

它只发生在'‘，而不是发生在任何其他用户，我知道。这个非常相似但运行时间较短的示例运行得很好：

$ sudo -u <the_user> srun --pty sleep 20
srun: job 110963 queued and waiting for resources
srun: job 110963 has been allocated resources

注意，当我以自己的身份运行srun --pty sleep 20时，srun不会输出两个srun: job...行。在我看来，这似乎是一个额外的指示，即srun受“”的一些不同设置的限制。

我检查过的所有设置对于“”和其他用户都是一样的。我已经检查过了，“MaxWall”不是为这个用户设置的，也不是为任何其他用户设置的。属于同一Slurm帐户的其他用户不会遇到此问题。

This question听起来是相关的，但我不认为解释似乎是一样的。

是什么导致了这一切？

更新-地块使变厚

当这个不幸的用户的作业被分配时，我在‘/var/log/slurm/slurmctld.log’中看到这条消息：

sched: _slurm_rpc_allocate_resources JobId=111855 NodeList=<node>

不久之后，我看到了这样的信息：

select/cons_tres: common_job_test: no job_resources info for JobId=110722_* rc=0

作业110722_*是另一个用户由于“QOSMaxGRESPerUser”而挂起的挂起的数组作业。这个数组作业(110722_57)的一个悬而未决的部分最终在111855被杀死时接管了作业111855的CPU核心。这使我相信110722_57会导致111855人死亡。然而，110722_57之后仍然悬而未决。

我在这里不明白的一些事情是：

为什么一个待处理的作业会杀死另一个作业，而仍然悬而未决的afterwards?

• How --一个悬而未决的作业--一开始甚至有权利杀死另一个作业？

• ，为什么这只会影响‘_user’>的作业，而不会影响其他用户的作业？

这一切都不是故意要发生的。我猜想它一定是由某些特定于“”的设置引起的，但是我不知道它们是什么，而且它们不应该是这样的。如果这些设置是我们管理员以某种方式造成的，那是无意的。

更新2

这个问题神奇地消失了，再也不能重现了。

注:一些细节已被匿名为<something>以上。