Завершение работы зомби SLURM

Я столкнулся со следующей проблемой во время первого жесткого отключения кластера отдела, за который я отвечаю. Система работает под управлением SLURM 17.11 и использует MariaDB/SQL для хранения учетных данных.

Чтобы выполнить обновление памяти, мне пришлось отключить сервер управления и базы данных кластера, который использует SLURM в качестве планировщика. После перезапуска управляющий демон отказался запускаться, так как, очевидно, состояние сохранения файлов в /var/spoolне было правильных разрешений больше. Поэтому я сделал выделенную папку /var/spool/slurm_stateдля файлов состояния грязи и сменили владельца на slurm:slurm, После модификации sulrm.conf установить правильное StateSaveLocation контрольный демон запущен, и я могу представить тестовые задания.

Однако я не копировал старые файлы состояния в новое местоположение. Таким образом, новые задания снова начались с JobID 1. После осознания того, что я быстро прекратил работу slurmctld и изменился StateSaveLocation вернуться к /var/spool (с соответствующими изменениями группы и разрешений).

Теперь одно тестовое задание, которое выполнялось после выключения демона управления, застревает в базе данных с состоянием, установленным в RUNNINGsystemverwalter 2 240 9-21:40:55 100.0 RUNNING allgather_latency_240_mpichпросто накапливая время выполнения для учетной записи.

Я пытался прекратить работу через scancel как пользователь, а также как root, но безрезультатно. Ни у кого не было попытки приостановить работу, используя scontrol привело к желаемому результату.

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

Источник

2 ответа

Решение

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

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

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

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

Источник

Следующая команда выведет список вышедших из-под контроля заданий и предложит их удалить:

sacctmgr show runawayjobs

Источник
Другие вопросы по тегам