SLURM now requires cgroups for basic functionality. As a result, sysutils/slurm-wlm is currently broken and unlikely to be fixed, unless someone is up for a long-term uphill battle. The port builds and installs, but the daemons don't work without the cgroups plugin. I'd suggest making it a default-off option for openmpi and mpich.
I'm not against it in principle, I think that not having a base dependency on slurm has its own merit even if slurm-wlm is not broken. I'll do some reading because I wasn't aware that slurm-wlm was currently broken, and I'll also do some tests.
Bug 276001
If I understand well <https://slurm.schedmd.com/cgroups.html>, cgroup is only an optional feature for SLURM. What am I missing?
(In reply to Jason W. Bacon from comment #0) I'm not sure I understand well. Are you saying that slurmctld fails with cgroup, but that if TaskPlugin is set to task/affinity or task/none then slurmctld also fails? https://slurm.schedmd.com/slurm.conf.html#OPT_TaskPlugin
Is anyone actually *running* SLURM on FreeBSD? It's been a while since I've tried, but I was unable to get anything later than 20.02.7 working. Bug 276001 was my last attempt, and I only got as far as unbreaking the build. I don't recall the details of why the daemons wouldn't run. I have always used task/affinity, and it was no longer working last time I checked. FYI, I ported SLURM to FreeBSD. There are many features that never worked due to Linuxisms (like parsing /proc files with scanf()), and the task of keeping it working has grown with each new release. Upstream isn't interested in supporting other platforms, and in fact only provides significant support to paying customers. I finally gave up and started https://github.com/outpaddling/LPJS/. At any rate, making SLURM an unconditional dependency for MPI seemed questionable to me from the beginning, though I understood the desire to avoid creating multiple packages.
When I proposed an upgrade of sysutils/slurm-wlm in Phabricator D42764 and asked for checking from its users, I got no answer on this point: then I guess that it is not widely used, excepted for the libraries. The question is: which is the impact of removing this dependency on MPICH and OpenMPI?
So, the dependency was in response to my request to support SLURM in OpenMPI. The maintainer at the time decided to make it unconditional rather than use flavors or some other mechanism to create alternative packages. I think a default-off option for SLURM support would be more than adequate at this point. If someone wants to do the work to get SLURM working on FreeBSD again, this can always be reexamined.