Slurm集群中特定用户作业运行20-25秒后被强制终止的原因排查

安全阿岳

2026-4-29

Slurm集群单用户作业异常终止问题分析

根据你描述的Slurm集群异常情况——仅特定用户的作业运行20-25秒就被强制终止，结合日志细节和后续的状态变化，我梳理了几个可能的成因和对应的解答：

核心现象回顾

仅<the_user>的作业会在20-25秒后被终止，其他用户无此问题；运行sudo -u <the_user> srun --pty sleep 25必现错误，sleep 20则正常。
slurmctld日志显示_slurm_rpc_kill_job: REQUEST_KILL_JOB JobId=xxx uid <the_users_uid>，说明终止命令由Slurm控制节点发起。
更新阶段发现，待处理的阵列作业（因QOSMaxGRESPerUser限制排队）在异常作业被终止后接管了其CPU核心，但自身仍处于待处理状态。
问题最终自行消失，无法复现。

虽然你确认未设置MaxWall，但Slurm可能存在针对该用户的隐性资源限制：

该用户可能被误绑定到某个QOS，而该QOS配置了MaxCPUPerUser或MaxGRESPerUser的动态阈值。当作业运行到20-25秒时，资源使用触发了限制，调度器主动终止作业释放资源，试图分配给队列中等待的作业。
结合阵列作业因QOSMaxGRESPerUser排队的情况，可能调度器的资源抢占逻辑出现异常——通常抢占需要显式配置PreemptMode，但如果是调度器bug，可能出现待处理作业“间接触发”已运行作业终止的情况。

从更新的日志select/cons_tres: common_job_test: no job_resources info for JobId=110722_* rc=0来看，这是cons_tres插件的异常输出，说明调度器在处理阵列作业的资源信息时出现了错误：

这种错误可能导致调度器误判该用户的作业“超额占用资源”，从而触发强制终止。
阵列作业之所以接管核心却仍待处理，是因为它本身受QOSMaxGRESPerUser限制，仅能抢占部分资源，无法满足完整的作业启动条件，因此继续处于排队状态。

如果集群启用了cgroup作业控制，该用户可能被意外设置了CPU时间配额：

检查/sys/fs/cgroup/cpu/user.slice/user-<the_users_uid>.slice下的cpu.cfs_quota_us和cpu.cfs_period_us参数。如果cpu.cfs_quota_us等于25000000（对应25秒），说明是内核通过cgroup限制终止了进程，Slurm只是捕获到终止事件并记录日志。
这种限制通常不是Slurm配置的，而是操作系统层面的误操作，且仅针对该用户。

Slurm控制节点与计算节点之间的状态同步偶尔会出现异常：

待处理作业为何能终止其他作业，自身却仍保持待处理状态？
并非待处理作业主动终止了其他作业，而是调度器（或cgroup限制）终止了原作业，释放的资源被调度器标记为可用。阵列作业尝试抢占这些资源，但因QOSMaxGRESPerUser限制无法满足完整的启动条件，因此继续处于待处理状态，只是临时占用了释放的核心。
待处理作业为何拥有终止其他作业的权限？
待处理作业并没有终止权限，终止操作是Slurm控制节点发起的。日志中的_slurm_rpc_kill_job是slurmctld自身的操作，而非其他用户作业的请求。
为何此异常仅影响<the_user>的作业？
大概率是该用户被绑定了特殊的QOS、操作系统层面的cgroup限制，或者Slurm调度器在处理该用户的作业时触发了特定bug（比如用户UID与某个阵列作业的ID存在冲突，导致资源计算错误）。

检查用户的QOS关联：运行sacctmgr show user <the_user> format=user,qos，确认是否有未预期的QOS绑定。
核查cgroup配置：查看/sys/fs/cgroup/cpu/user.slice/user-<the_users_uid>.slice/cpu.cfs_quota_us和cpu.cfs_period_us的值，判断是否存在CPU时间限制。
检查QOS抢占配置：运行sacctmgr show qos format=name,preemptmode,maxgresperuser，确认是否有QOS配置了抢占模式。
重启Slurm服务：重启slurmctld和所有节点的slurmd服务，强制集群状态同步。

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