SLURM Reference Guide

Using the Slurm job scheduler

Important note

This guide is an introduction to the Slurm job scheduler and its use on ARC's clusters. ARC compute nodes typically have two 8 core processors and a range of memory sizes, from 64GB to 256GB; however, there are some nodes with more (or fewer) cores and/or memory. In addition, some nodes in Arcus-HTC have NVidia Tesla GPGPU cards (K40, K80, P100 or V100). 


Jobs are run as batch jobs, i.e. in an unattended manner. Typically a user logs in to the login nodes (e.g., prepares a job (which contains details of the work to carry out and the computer resources needed) and submits it to the job queue. The user can then log out (if she/he wishes) until their job has run, to collect the output data.

Jobs are managed by Slurm, which is in charge of

  • allocating the computer resources requested for the job,
  • running the job and
  • reporting the outcome of the execution back to the user.

Running a job involves, at the minimum, the following steps

  • preparing a submission script and
  • submitting the job to execution.

This guide describes basic job submission and monitoring for Slurm.  The topics in the guide are:


The table below gives a short description of the most used Slurm commands.

command description
sacct report job accounting information about active or completed jobs
salloc allocate resources for a job in real time (typically used to allocate resources and spawn a shell, in which the srun command is used to launch parallel tasks)
sbatch submit a job script for later execution (the script typically contains one or more srun commands to launch parallel tasks)
scancel cancel a pending or running job
sinfo reports the state of partitions and nodes managed by Slurm (it has a variety of filtering, sorting, and formatting options)
squeue reports the state of jobs (it has a variety of filtering, sorting, and formatting options), by default, reports the running jobs in priority order followed by the pending jobs in priority order

used to submit a job for execution in real time

All Slurm commands have extensive help through their man pages e.g.

man sbatch

Will show you the help pages for the sbatch command.

Preparing a submission script

A submission script is a shell script that

  • describes the processing to carry out (e.g. the application, its input and output, etc.) and
  • requests computer resources (number of cpus, amount of memory, etc.) to use for processing.

The simplest case is that of a job that requires a single node (this is the smallest unit we allocate on arcus-b) with the following requirements:

  • the job uses 1 node,
  • the application is a single process,
  • the job will run for no more than 100 hours,
  • the job is given the name "test123" and
  • the user should be emailed when the job starts and stops or aborts.

Example 1: job running on a single node

Supposing the application is called myCode and takes no command line arguments, the following submission script runs the application in a single job

    # set the number of nodes
    #SBATCH --nodes=1
    # set max wallclock time
    #SBATCH --time=100:00:00
    # set name of job
    #SBATCH --job-name=test123
    # mail alert at start, end and abortion of execution
    #SBATCH --mail-type=ALL
    # send mail to this address
    # run the application

The script starts with #!/bin/bash (also called a shebang), which makes the submission script a Linux bash script.

The script continues with a series of lines starting with #, which represent bash script comments.  For Slurm, the lines starting with #SBATCH are directives that request job scheduling resources.  (Note: it's very important that you put all the directives at the top of a script, before any other commands; any #SBATCH directive coming after a bash script command is ignored!)

The resource request #SBATCH --nodes=n determines how many compute nodes a job are allocated by the scheduler; only 1 node is allocated for this job.  A note of caution is on threaded single process applications (e.g. Matlab).  These applications cannot run on more than a single compute node; allocating more (e.g. #SBATCH --nodes=2) will end up with the first node being busy and the rest idle.

The maximum walltime is specified by #SBATCH --time=T, where T has format hh:mm:ss.  Normally, a job is expected to finish before the specified maximum walltime.  After the walltime reaches the maximum, the job terminates regardless whether the job processes are still running or not. 

The name of the job can be specified too with #SBATCH --job-name="name"

Lastly, an email notification is sent if an address is specified with #SBATCH --mail-user=<email_address>.  The notification options can be set with #SBATCH --mail-type=<type>, where <type> may be BEGINENDFAILREQUEUE or ALL (for any change of job state).

The final part of a script is normal Linux bash script and describes the set of operations to follow as part of the job.  The job starts in the same folder where it was submitted (unless an alternative path is specified), and with the same environment variables (modules, etc.) that the user had at the time of the submission.  In this example, this final part only involves invoking the myCode application executable.

Example 2: job running on multiple nodes

As a second example, suppose we want to run an MPI application called myMPICode with the following requirements

  • the run uses 2 nodes,
  • the job will not run for more than 100 hours,
  • the job is given the name "test123" and
  • the user should be emailed when the job starts and stops or aborts.

Supposing no input needs to be specified, the following submission script runs the application in a single job

    # set the number of nodes and processes per node
    #SBATCH --nodes=2
    # set the number of tasks (processes) per node.
    #SBATCH --ntasks-per-node=16
    # set max wallclock time
    #SBATCH --time=100:00:00
    # set name of job
    #SBATCH --job-name=test123
    # mail alert at start, end and abortion of execution
    #SBATCH --mail-type=ALL
    # send mail to this address

    mpirun $MPI_HOSTS myMPICode

In large part, the script above is similar to the one for a single node job except in this example, #SBATCH --ntasks-per-node=m is used to reserve m cores per node and to prepare the environment for a MPI parallel run with m processes per each compute node (the "." line is used to correctly set up environment variables for the MPI job).

The preferred MPI implementation on arcus-b is MVAPICH2.

Slurm partitions

Slurm partitions are essentially different queues that point to collections of nodes.

On Arcus-b there are two partitions:

  • compute - this is the default partition (queue) and the one your jobs will go to if you do not specify a partition in your job submission script. Most of the arcus-b compute nodes are in this partition.
  • devel - this partition (queue) has four compute nodes that have been set aside for testing jobs before they are submitted to the main compute partition (essentially to make sure the submission scripts work). This partition has a maximum time limit of 10 minutes.

On Arcus-HTC there are also three partitions:

  • htc - the default partition; contains all CPU nodes and most of the GPU resources. This is the partition you will most likely want to use.
  • htc-nova - the 'novel architectures' partition; it contains nodes with non-standard hardware (KNL; Titan RTX cards) or operating system (nvidia DGX1V)
  • htc-devel - the development partition; for testing jobs. Contains two compute nodes and one K40 GPU node. This partition has a maximum time limit of 10 minutes.

You can specify the Slurm partition by adding the #SBATCH --partition= directive to the top of your submission script so adding:

#SBATCH --partition=devel 

will send your job to the devel partition. Alternatively, the partition can be supplied with the sbatch command like this:

sbatch --partition=htc-devel

Defining a partition on the sbatch command line takes precedence over the definition in the jobscript.

You can see the current state of the partitions with the sinfo command. 

All Slurm commands have extensive help through their man pages; try e.g.

man sbatch

Submitting jobs with the command sbatch

Once you have a submission script ready (e.g, the job is submitted to the execution queue with the command sbatch  The queueing system prints a number (the job id) almost immediately and returns control to the linux prompt.  At this point the job is in the submission queue.

Once you have submitted the job, it will sit in a pending state until the resources have been allocated to your job (the length of time your job is in the pending state is dependent upon a number of factors including how busy the system is and what resources you are requesting). You can monitor the progress of the job using the command squeue (see below).

Once the job starts to run you will see files with names such as slurm-1234.out either in the directory you submitted the job from (default behaviour) or in the directory where the script was instructed explicitly to change to. 

Monitoring jobs with the command squeue

squeue is the main command for monitoring the state of systems, groups of jobs or individual jobs.

The command squeue prints the list of current jobs.  The list looks something like 

2497 compute test1.14 bob R 0.07 1> cnode1192
2499 compute test1.35 mary R 0.22 4 cnode(1101-1104)
2511 compute ask.for. steve PD 0.00 4 (Resources)

The first column gives the job ID, the second the partition (or queue) where the job was submitted, the third the name of the job (specified by the user in the submission script) and the fourth the owner of the job.  The fifth is the status of thejob (R=running, PD=pending, CA=cancelled, CF=configuring, CG=completing, CD=completed, F=failed). The sixth column gives the elapsed time for each particular job.  Finally, there are the number of nodes requested and the nodelist where the job is running (or the cause that it is not running).

Some other useful squeue features include:

  • -u for showing the status of all the jobs of a particular user, e.g. squeue -u bob for user bob;
  • -l for showing more of the  available information;
  •  --start to report  the  expected  start  time  of pending jobs.

Read all the options for squeue on the Linux manual using the command man squeue, including how to personalize the information to be displayed.

Deleting jobs with the command scancel

Use the scancel command to delete a job, e.g. scancel 1121 to delete job with ID 1121.  A user can delete his/her own jobs at any time, whether the job is pending (waiting in the queue) or running.  A user cannot delete the jobs of another user.  Normally, there is a (small) delay between the execution of the scancel command and the time when the job is dequeued and killed.  Occasionally a job may not delete properly, in which case, the ARC support team can delete it upon request.

Environment variables

At the time a job is launched into execution, Slurm defines multiple environment variables, which can be used from within the submission script to define the correct workflow of the job.  The most useful of these environment variables are the following:

  • SLURM_SUBMIT_DIR, which points to the directory where the sbatch command is issued;
  • SLURM_JOB_NODELIST, which returns the list of nodes allocated to the job;
  • SLURM_JOB_ID, which is a unique number Slurm assigns to a job.

In most cases, SLURM_SUBMIT_DIR does not have to be used, as the job goes by default to the directory where the slurm command was issued.  This behaviour of Slurm is in contrast with other schedulers, such as Torque, which goes to the home directory of the user account.  SLURM_SUBMIT_DIR can be useful in a submission script when files must be copied to/from a specific directory that is different from the directory where the slurm command was issued.

SLURM_JOB_ID is useful to tag job specific files and directories, typically output files or run directories.  For instance, the submission script line

myApp > $SLURM_JOB_ID.out

runs the application myApp and redirects the standard output to a file whose name is given by the job ID.  The job ID is a number assigned by Slurm and differs from the character string name given to the job in the submission script by the user.

Job Dependencies

Job dependencies are used to defer the start of a job until the specified dependencies have been satisfied.

They are specified with the --dependency option to sbatch in the format:

 sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...

Dependency types:

after:jobid[:jobid...] job can begin after the specified jobs have started
afterany:jobid[:jobid...] job can begin after the specified jobs have terminated
afternotok:jobid[:jobid...] job can begin after the specified jobs have failed
afterok:jobid[:jobid...] job can begin after the specified jobs have run to completion with an exit code of zero

For example:

sbatch --dependency=afterok:1802051

In the above example, job script is submitted and is given a JobID of 1802051. We then submit with a dependency that it only run when job 1802051 has completed.

Job Arrays

Job arrays offer a mechanism for submitting and managing collections of similar jobs quickly and easily. In general, job arrays are useful for applying the same processing routine to a collection of multiple input data files. Job arrays offer a very simple way to submit a large number of independent processing jobs.

By submitting a single job array sbatch script, a specified number of “array-tasks” will be created based on this “master” sbatch script. 

For example:

    #SBATCH --job-name=arrayJob
    #SBATCH --output=arrayJob_%A_%a.out
    #SBATCH --error=arrayJob_%A_%a.err
    #SBATCH --array=1-4
    #SBATCH --time=02:00:00

    # Print this sub-job's task ID

    # Run "application" using input filename modified by SLURM_ARRAY_TASK_ID
    ./application input_$SLURM_ARRAY_TASK_ID.txt

The above example uses the --array=1-4 specification to create four array tasks which run the command "application" on different input files, the filename of each being modified by the SLURM_ARRAY_TASK_ID variable. 

The %A_%a construct in the output and error file names is used to generate unique output and error files based on the master job ID (%A) and the array-task's ID (%a). In this fashion, each array-task will be able to write to its own output and error file.

For clarity, the input and output files for the above script, if submited as jobID 1802055 would be:

JobID --output --error Application Input filename
1802055_1 arrayJob_1802055_1.out arrayJob_1802055_1.err input_1.txt
1802055_2 arrayJob_1802055_2.out arrayJob_1802055_2.err input_2.txt
1802055_3 arrayJob_1802055_3.out arrayJob_1802055_3.err input_3.txt
1802055_4 arrayJob_1802055_4.out arrayJob_1802055_4.err input_4.txt

Note: You can specifiy the --array option on the sbatch command line instead of inside the submission script. For example if the --array option was removed from the above script and the script was named the command would be:

sbatch --array=1-4

More information about Slurm job arrays can be found in the Slurm Job Array Documentation