跳转至

故障报告：Slurm 26.05 升级后普通用户 srun 报 "Error generating job credential"

故障时间

  • 2026-09-03 08:25 ~ 08:50（首次用户报障至修复完成）
  • 背景：2026-09-02 完成 Slurm 21.08 → 26.05.2 全新部署 + configless 模式启用

现象

  1. submit 节点（IDE / 192.168.0.9）普通用户 rain01 执行 srun hostname 报错： srun: error: Unable to create step for job 9: Error generating job credential
  2. 同期 sacct 报 Unable to connect to database（独立原因：k8s 集群升级导致 MariaDB 容器暂不可用，与本案无关）
  3. 反例：root 身份在控制节点执行 srun 完全正常，作业成功运行

影响范围

  • 所有普通用户的作业提交（srun/sbatch/salloc）全部失败
  • root 作业不受影响（掩盖问题，导致昨日部署验证未暴露）
  • 集群 slurmctld/slurmd/slurmdbd 服务本身正常，节点全部 idle

根因原理（三层叠加）

第一层：触发条件 — k8s 升级期间 LDAP 服务不可达

本集群使用 LDAP 统一认证（openldap pod 在 k8s 192.168.0.2 上），控制节点/计算 节点通过 nslcd 连接 ldap://192.168.0.2/，submit 节点通过 sssd 连接同一 LDAP。 k8s 升级导致 openldap-0 pod 重启不可达 → nslcd 断连（日志： no available LDAP server found: Can't contact LDAP server）→ getent passwd rain01 在所有非 submit 节点只剩本地 files 源 → 本地 files 源没有 rain01 → 查询为空。

第二层：Slurm 26.05 新机制 — fetch_identity 强依赖控制节点能解析用户

Slurm 26.05 新增 identity 组件（src/common/identity.c），作业凭证（job credential） 生成机制变更：

  • 21.08 时代：credential 仅嵌入 uid/gid 数字，用户名由各执行节点本地解析
  • 26.05 起：slurm_cred_create() 调用 fetch_identity(uid, gid, group_names) 在 slurmctld 本机解析作业用户的完整身份（用户名 + 组名列表）并嵌入凭证， 解析失败直接返回 ESLURM_INVALID_JOB_CREDENTIAL

LDAP 不通 → slurmctld 本机解析失败 → fetch_identity() 返回 NULL → 凭证生成失败。

第三层：submit 节点 sssd 缓存掩盖了问题

submit 节点 sssd 有缓存，LDAP 短暂不可达时仍能返回 rain01，导致"用户确实存在"的 错觉，掩盖了 LDAP 服务不可达这一上游根因。

错误码调用链（源码证据）：

stepmgr.c:5350  return ESLURM_INVALID_JOB_CREDENTIAL;   ← slurm_cred_create() 返回 NULL 时
interfaces/cred.c:227  if (!(arg->id = fetch_identity(...)))  ← 用户不存在时返回 NULL

证据摘要

  1. slurmctld 日志（关键报错，08:25 起持续出现）： error: slurm_cred_create: fetch_identity() failed error: slurm_cred_create error
  2. nslcd 日志（0.2 控制节点，k8s 升级期间断连）： nslcd: ... no available LDAP server found: Can't contact LDAP server: Connection reset by peer nslcd: ... connected to LDAP server ldap://192.168.0.2/ ← 10:30 恢复
  3. LDAP 恢复后纯 LDAP 查询验证（清除本地用户后）： 192.168.0.2: getent passwd rain01 → rain01:x:2001:2000:rain01:... ✅ 192.168.0.5: getent passwd rain01 → rain01:x:2001:2000:rain01:... ✅ srun -N1 hostname → k8s-node-01 ✅
  4. 排除项（均有实测证据）：
  5. MUNGE key 全节点 md5 一致
  6. 时间同步正常（chronyc 偏差 0.000056s）
  7. 计算节点本机 munge 编解码正常
  8. root 作业全链路正常（排除 slurmctld/slurmd 服务问题）

解决方案

自愈路径：k8s 升级完成 → openldap-0 pod 恢复 → nslcd 自动重连（10:30 恢复）→ getent passwd rain01 重新可用 → fetch_identity() 解析成功 → srun 恢复。

人工干预（临时绕过）： 1. 在控制节点与计算节点幂等补建本地用户（uid/gid 与 LDAP 一致）： bash for host in 192.168.0.2 192.168.0.5 192.168.0.6 192.168.0.7; do getent group teama >/dev/null || groupadd -g 2000 teama getent passwd rain01 >/dev/null || useradd -u 2001 -g 2000 -c rain01 \ -d /mnt/nfs/slurm/users/rain01 -s /bin/csh -M rain01 done 注：LDAP 恢复后已清除本地用户，现完全依赖 LDAP

  1. 补充修复：192.168.0.7 缺少 /bin/csh，安装 yum install -y tcsh 注：已安装并保留（纯 LDAP 不管理 /bin/csh 包安装）

验证结果

  1. submit 节点以 rain01 身份（家目录为工作目录）： srun -N1 hostname → k8s-node-01 （成功） srun -N3 hostname → k8s-node-01/02/03 全部返回（成功）
  2. NFS 家目录跨节点访问正常（uid 2001 一致，权限 rwxrwxrwx）
  3. sacct 数据库问题待 k8s 升级完成后自愈（MariaDB 容器恢复即可）

预防建议

  1. 部署脚本 pre_check 增加 LDAP 连通性检测（高优先级）： 部署 Slurm 前，对所有节点执行 getent passwd <testuser> 验证 LDAP 可达性， 不可达时直接报错退出，不继续部署。当前脚本缺失此检查。
  2. Slurm 26.05 必须保证控制节点能解析作业用户（高优先级）： 26.05 的 fetch_identity() 在 slurmctld 本机执行，而非作业节点。 LDAP/NSS 在控制节点必须可靠可用，建议配置 sssd 作为主 + nslcd 作为备， nsswitch 顺序保证 LDAP 优先。
  3. 避免 Slurm 集群控制节点与 LDAP 共享 k8s master： 本次故障中 LDAP pod 在 k8s master（192.168.0.2），k8s 升级时 LDAP 中断 直接影响 Slurm 控制节点的用户解析。建议 LDAP 独立部署在非 Slurm 控制节点上 或部署 LDAP slave pod 到其他 k8s node。
  4. 部署验收必须包含普通用户提交用例： 仅 root 验证无法暴露 LDAP 用户解析类故障。
  5. shell 依赖：用户 shell 为 csh 时，所有执行节点需预装 tcsh 包。

来源：/home/rain/Documents/slurm/slurm_ins/docs/故障报告-20260903-普通用户srun凭证生成失败.md ｜ 最后更新：2026-09-03 15:20（由 build/sync.py 同步，请勿在站点侧修改）