花了一晚上修的一个 bug. 记录一下. 先讲结论再讲故事.
slurmdbd 在更新 account 配置的时候, 有可能出现更新成功了, dump 出来是对的, 但跑程序失败 (requested resources not available) 的情况. 其中一个可能原因是 mysql 并没有成功写入, 于是认证失败. 解决方案是修改 slurmdbd 的配置文件, 使得其以 root 用户身份执行.
故事是实验室有同学要赶 PLDI, 需要独占某一些节点, 并防止懵懂的小朋友和他们抢占节点后不释放. laekov 给出的解决方案是在 slurm 中单独划分一个队列, 并仅对指定 account 开放. 这个操作 laekov 在另一个集群上已经熟练使用了. 但是 laekov 在用 sacctmgr 配置好 account 和 user 之后, 尝试 srun 任务, 发现提示 resources not available. 之前遇到过这种情况, 通过重启 slurmdbd 解决了问题. 但是这次重启任何 slurm 组件都没有解决问题.
laekov 查看了 /var/log/slurm-llnl/slurmctld, 发现提示 part_policy_valid_acct: job's account not known, so it can't use this partition. 疑惑的是在 srun 命令里面明明指定了 account, 为啥会找不到呢?
继续仔细看 log, 发现在 sacctmgr create 的时候会报另一个错 error: Update Association request from non-super user uid=. 于是大胆猜想 db 根本没有被成功写入. 果然, 在删除的时候也报了 error: Can't find parent id 的错, 说明最初创建的 account 也没有插成功! 在一番 google 之后找到了这个 issue 的回复, 指明 slurmdbd 如果被 slurm 用户执行的话, 权限得对. 于是 laekov 索性把 slurmdbd 扔给了 root 并重新插入了 accounts 和 users. 果然就能跑了.
这个问题最坑的地方在于虽然没有插入成功, 但是 sacctmgr 竟然能 show 和 dump 出失败的数据. 估计是因为迷之缓存. 这样让 laekov 茫然了很久, 查错也变得坑了起来. 这个集群的 slurm 版本比较早古 (2015). 据 harry 说在更新的版本中会直接报错了. 所以是时候换集群了(?