Я зіткнувся з такою проблемою під час першого жорсткого вимикання кластерного відділу, яким я відповідаю. Система працює 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призвела до бажаного результату.
Моє запитання таке: що мені робити, щоб припинити цю роботу? Чи потрібно вручну змінювати запис бази даних, чи є більш просте рішення?