Я столкнулся со следующей проблемой во время первого жесткого отключения кластера отдела, за который я отвечаю. Система работает под управлением SLURM 17.11 и использует MariaDB/SQL для хранения учетных данных.
Чтобы выполнить обновление памяти, мне пришлось отключить сервер управления и базы данных кластера, который использует SLURM в качестве планировщика.
После перезапуска управляющий демон отказался запускаться, поскольку файлы сохранения состояния в /var/spool , по-видимому, больше не имели правильных разрешений. Поэтому я создал специальную папку /var/spool/slurm_state для файлов состояния slurm и изменил владельца на slurm:slurm . После изменения sulrm.conf для установки правильного StateSaveLocation демон управления, и я смог отправить тестовые задания.
Однако я не копировал старые файлы состояния в новое местоположение. Таким образом, новые рабочие места начались снова с JobID 1.
После осознания того, что я быстро прекратил slurmctld и изменил StateSaveLocation обратно на /var/spool (с соответствующими изменениями группы и разрешений).
Теперь одно тестовое задание, которое выполнялось, когда демон управления был заблокирован, застревает в базе данных с состоянием, установленным в RUNNING systemverwalter 2 240 9-21:40:55 100.0 RUNNING allgather_latency_240_mpich только накапливая время выполнения для учетной записи.
Я пытался завершить работу через scancel как пользователь, а также как root , но безрезультатно.
Ни одна попытка приостановить работу с помощью scontrol привела к желаемому результату.
Мой вопрос таков: что я должен сделать, чтобы прекратить эту работу? Нужно ли вручную изменять запись в базе данных или есть более простое решение?