Прекращение работы зомби SLURM

332
Nox

Я столкнулся со следующей проблемой во время первого жесткого отключения кластера отдела, за который я отвечаю. Система работает под управлением 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привела к желаемому результату.

Мой вопрос таков: что я должен сделать, чтобы прекратить эту работу? Нужно ли вручную изменять запись в базе данных или есть более простое решение?

0

1 ответ на вопрос

0
Nox

Хорошо. Я нашел довольно тривиальное решение этой проблемы, хотя я не думаю, что оно будет работать всегда.

Чтобы устранить такой процесс зомби, выполните следующие действия:

  1. Запустите менеджер учетной записи SLURM через sacctmgrпользователя с Operatorучетной записью (или root).
  2. Поиск сбежавших рабочих мест, выдав list runawayjobsв sacctmgrподсказке.
  3. Если система распознает одно или несколько заданий без конечной даты, т. Е. Потерянных (сбежавших) заданий, она запросит, хотите ли вы это исправить. Подтвердите с помощью Y.

Эти шаги позволили решить мою проблему после того, как в sacctотчетах было 9 дней безудержной работы .

Похожие вопросы