Skip to content

Read Slurm configuration as a system

Audience: Authorized administrators · Reviewed: 2026-10-04

Version and teaching scope

Use documentation matching your installed release and local policy. Check sinfo --version; upstream documentation identified itself as 26.05 at review. Paths, partitions, accounts, modules, memory, MPI, GPUs and services are site-specific. Example programs beginning ./ must already exist. These are teaching examples, not a validated deployment recipe or evidence that a cluster was modified. Administrative operations require authorized operators and a reviewed change plan; ordinary users must not execute them or paste them into production.

A conceptual configuration fragment

slurm.conf describes the cluster, nodes, partitions, and scheduler choices. The following is a partial conceptual fragment, not a runnable complete configuration. Inventories, paths, ownership, authentication, plugins, and service setup must be completed for your environment.

# Conceptual example; administrator review required.
ClusterName=teaching
SlurmctldHost=controller01
SlurmUser=slurm
StateSaveLocation=/var/lib/slurm/ctld
SlurmdSpoolDir=/var/lib/slurm/slurmd
SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
# Insert measured NodeName definitions here.
PartitionName=teaching Nodes=compute[01-02] Default=YES MaxTime=01:00:00 State=UP

Measure hardware and test containment

Use slurmd -C on each hardware class to inspect the detected CPU topology and memory. Do not invent node core counts or configure all physically installed RAM as safely allocatable: the OS and daemons need room. The partition above references nodes that must be defined separately.

Resource selection, tracking, binding, and enforcement are different layers. select/cons_tres models consumable resources; cgroup/task settings govern containment. Confirm the OS supports the chosen cgroup mode and test CPU, memory, and device isolation with harmless jobs. Selecting a memory-aware allocation policy alone is not proof that memory limits are enforced.

Persistent accounting and access policy

For persistent accounting, the controller talks to slurmdbd, which manages a supported database. Protect database credentials in slurmdbd.conf; do not put them in user-readable configuration. Accounts and associations connect a user, cluster, account, and optionally partition. Define the intended enforcement policy explicitly: collecting accounting records alone does not establish every desired submission limit.

Configless does not replace provisioning

Configless operation distributes selected Slurm configuration through the controller, but does not remove the need to provision identity, keys, software, directories, and mounts. Validate reload-versus-restart requirements for each changed parameter.

Checkpoint: In the lab, verify allocation containment and a completed job's accounting record.

Official sources

Previous: Identity, time, network, and authentication · Learning path · Next: Partitions, QOS, fair share, and honest requests