Slurm Cheatsheet for CCS Cluster

#slurm#cheatsheet#ccs cluster#job management#node status

Useful commands for managing Slurm jobs and checking CCS cluster status.

Job Management

Check Queue

# Show your active/pending jobs
squeue -u $USER

# Show all jobs on the specific partition
squeue -p H8V141_SAP112M2000_L

# Estimate start time for pending jobs
squeue --start -u $USER

Control Jobs

# Cancel a specific job
scancel <JOB_ID>

# Cancel all your jobs
scancel -u $USER

# Hold a job (prevent it from starting)
scontrol hold <JOB_ID>

# Release a held job
scontrol release <JOB_ID>

# Requeue a job from the beginning
scontrol requeue <JOB_ID>

Update a pending job

Change an existing allocation request without cancelling or resubmitting. The job ID and dependencies remain unchanged.

# Check that the job is still pending
scontrol show job <JOB_ID>

# Set the total time limit to 24 hours (days-hours:minutes:seconds)
scontrol update JobId=<JOB_ID> TimeLimit=1-00:00:00

# Request four GPUs
scontrol update JobId=<JOB_ID> Gres=gpu:4

# Update both together
scontrol update JobId=<JOB_ID> Gres=gpu:4 TimeLimit=1-00:00:00

# Verify the updated request and estimated start time
scontrol show job <JOB_ID>
squeue -u "$USER" -o "%.18i %.10T %.12l %.20b %.35E"
squeue --start -u "$USER"

These commands set new limits, not extra hours. Cluster permissions and partition or QoS limits still apply. Increasing a running job's time limit may require an administrator. Start times and scheduled nodes are estimates, not guarantees.

Editing #SBATCH lines in your local script does not update an already submitted job; Slurm keeps the submitted script. Use scontrol for pending resource changes and edit the script separately for future submissions. CPU and memory requests do not automatically shrink when you reduce GPUs.

Update any external configuration before the job reads it. The launcher must use the allocated GPU count rather than a hard-coded process count. If coordinating several edits, hold the pending job first and release it after verifying the request and config.

Job arrays

An array submits many copies of the same job script. Slurm assigns each copy a different SLURM_ARRAY_TASK_ID, which the script can use to select a config, input file, or random seed. In 0-9%4, 0-9 creates ten tasks and %4 limits the array to four concurrent tasks. Common uses include parameter sweeps, dataset shards, cross-validation folds, and repeated runs with different seeds.

Submit an array

sbatch --array=0-9%4 job.sh

Use the task ID inside job.sh:

python train.py "configs/${SLURM_ARRAY_TASK_ID}.yaml"

Change parameters per task

CONFIGS=(cnn.yaml vit.yaml impala.yaml)
SEEDS=(10 20 30)
INDEX="$SLURM_ARRAY_TASK_ID"

python train.py "${CONFIGS[$INDEX]}" "training.seed=${SEEDS[$INDEX]}"

Pass a shared variable

sbatch --array=0-2 --export=ALL,DATASET=gradients_train.h5 job.sh

Inside job.sh:

python train.py "${CONFIGS[$SLURM_ARRAY_TASK_ID]}" "data.h5_path=$DATASET"

Choose task ranges

sbatch --array=0-9 job.sh      # Tasks 0 through 9
sbatch --array=1,4,8 job.sh    # Only tasks 1, 4, and 8
sbatch --array=0-20:5 job.sh   # Tasks 0, 5, 10, 15, and 20
sbatch --array=0-20%4 job.sh   # At most four concurrent tasks

Separate task logs

%A is the array job ID and %a is the task ID.

#SBATCH --output=logs/%A_%a.out

Cancel array tasks

scancel <ARRAY_JOB_ID>_<TASK_ID>
scancel <ARRAY_JOB_ID>

Array tasks share the same CPU, GPU, memory, and time requests. Use separate arrays when runs need different resources.

Dependent jobs

# Submit only after the first job succeeds
FIRST_JOB=$(sbatch --parsable first.sh)
SECOND_JOB=$(sbatch --parsable --dependency="afterok:${FIRST_JOB}" second.sh)

# Wait for two jobs
sbatch --dependency="afterok:${JOB_A}:${JOB_B}" next.sh

# Run after completion regardless of success or failure
sbatch --dependency="afterany:${JOB_ID}" cleanup.sh

# Run only if the dependency fails
sbatch --dependency="afternotok:${JOB_ID}" recover.sh

Job details and logs

Check before submission

Validate the request and estimate when it could start without submitting it:

sbatch --test-only job.sh

Inspect pending and running jobs

# Show requested resources, dependencies, and pending reason
scontrol show job <JOB_ID>

# Show pending reason and estimated priority
squeue -j <JOB_ID> -o "%.18i %.10T %.30R"
sprio -j <JOB_ID>

# Show live CPU and memory use
sstat -j <JOB_ID>.batch --format=JobID,AveCPU,MaxRSS,MaxVMSize

# Compact queue view
squeue -u "$USER" -o "%.18i %.24j %.10T %.12M %.30R"

Review job history

# One job
sacct -j <JOB_ID> --format=JobID,State,Elapsed,ExitCode,MaxRSS,AllocTRES

# All jobs submitted today
sacct -u "$USER" -S today \
  --format=JobID,JobName,Partition,State,Elapsed,ExitCode,MaxRSS

Inspect scripts and logs

# Print the submitted batch script
scontrol write batch_script <JOB_ID> -

# Follow output and error logs
tail -f logs/out_<JOB_ID>.log
tail -f logs/err_<JOB_ID>.log

Common environment variables

# Show every Slurm variable available to the job
env | sort | grep '^SLURM_'

# Common examples
echo "$SLURM_JOB_ID"
echo "$SLURM_JOB_NAME"
echo "$SLURM_SUBMIT_DIR"
echo "$SLURM_JOB_NODELIST"
echo "$SLURM_CPUS_PER_TASK"
echo "$SLURM_ARRAY_JOB_ID"
echo "$SLURM_ARRAY_TASK_ID"

Node & Resource Status

Check Node Details

# Show detailed status of a specific node (e.g., ghnode001)
scontrol show node <NODE_NAME>
# Look for 'AllocTRES' to see used resources vs 'CfgTRES' for total.

Check Partition Status

# Summary of all partitions
sinfo

# Partition, availability, time limit, nodes, state, CPUs, memory, and GPUs
sinfo -o "%P %a %l %D %t %C %m %G"

# Detailed node list for the partition
scontrol show partition H8V141_SAP112M2000_L

Interactive Jobs

Start an Interactive Session

# Request an interactive shell on a compute node (adjust time/resources as needed)
salloc --partition=H8V141_SAP112M2000_L --gres=gpu:1 --time=1:00:00
# Once allocated, run 'srun --pty bash' to get the shell

Enter an existing allocation

srun --jobid=<JOB_ID> --pty bash

Troubleshooting

Inspect Running Job

# SSH into the node running your job (find Nodelist from squeue)
ssh <NODE_NAME>

# Check GPU usage on the node
nvidia-smi

# Check process status
top -u $USER