Slurm
Workload manager and job scheduler for HPC clusters
Slurm patches crashes and heterogeneous-job hangs on two branches while 26.11 is in RC.
◆Recent moves
- 3d ago
v26.05.6: fixes heterogeneous-job hangs and a stepmgr crash
A maintenance release fixing PMIx hangs and aborts in heterogeneous job steps, a stepmgr crash in array tasks, a slurmd memory leak and nodes shown idle while still completing. It is the current stable line's cleanup ahead of 26.11.
View source ↗ - 3d ago
v25.11.9: heap corruption and slurmrestd read fixes
Backports crash fixes to the older 25.11 line, including heap corruption on failed RPC forwarding, an out-of-bounds read in slurmrestd and quote handling in runtime/oci. Routine branch maintenance.
View source ↗ - 8d ago
Slurm 26.11 RC1: threadpool on by default, OCI runtime plugin
The first 26.11 release candidate changes defaults: the slurmctld threadpool is on, RPC replies are always asynchronous, and OCI containers move to a runtime/oci plugin selected with a renamed --runtime flag. It is the biggest structural change in the feed since the 26.05 line began, and sites will need to review renamed slurm.conf options before upgrading.
View source ↗ - 10d ago
wickberg-test: Testsuite - Cover a --stepmgr step cancel in test_101_18
A testsuite commit, not a release: it checks that cancelling a --stepmgr job step records the owner, not root, in sacct. Hints at an accounting fix in the next point release.
View source ↗ - 1mo ago
v26.05.5
Slurm 26.05.5 fixes qstat -f output, a slurmd double free and a regression placing powered-down nodes incorrectly. A routine maintenance release.
View source ↗ - 2mo ago
Slurm 26.05.4 fixes 7 CVEs, including privilege escalation
v26.05.4 closes 7 CVEs on the current release branch — including a privilege escalation (operator → admin via accounting DB) and SQL injection via cluster names — alongside the usual bug fix sweep of memory leaks, crash paths, and heterogeneous job handling. For HPC clusters with multiple user roles, the privilege escalation fix is the most operationally critical.
View source ↗