Scheduling jobs
Instructor note
Total: 75 min (Teaching:45 min | Discussion: 0 min | Breaks: 0 min | Exercises: 30 min)
Objectives
Questions
What is a scheduler and why are they used?
How do I launch a program to run on any one node in the cluster?
How do I capture the output of a program that is run on a node in the cluster?
Objectives
Run a simple Hello World style program on the cluster.
Submit a simple Hello World style script to the cluster.
Use the batch system command line tools to monitor the execution of your job.
Inspect the output and error files of your jobs.
Keypoints
The scheduler handles how compute resources are shared between users.
Everything you do should be run through the scheduler.
A job is just a shell script.
If in doubt, request more resources than you will need.
Job scheduler
An HPC system might have thousands of nodes and thousands of users. How do we decide who gets what and when? How do we ensure that a task is run with the resources it needs? This job is handled by a special piece of software called the scheduler. On an HPC system, the scheduler manages which jobs run where and when.
The following illustration compares these tasks of a job scheduler to a waiter in a restaurant. If you can relate to an instance where you had to wait for a while in a queue to get in to a popular restaurant, then you may now understand why sometimes your job do not start instantly as in your laptop.
The scheduler used in this lesson is Slurm. Although Slurm is not used everywhere, running jobs is quite similar regardless of what software is being used. The exact syntax might change, but the concepts remain the same.
Discussion
Why do you think users sometimes are unhappy with scheduling systems?
Creating our first Slurm job
The most common use of the scheduler is to run your “workload” non-interactively. Any workload that you want to run on the cluster is called a job, and the process of using a
scheduler to run the job is called batch job submission. A workload is for instance your analysis that you want to run, like for instance your python script that analyses some data and creates some output. Your workload can be a combination of commands, for instance several python commands or python and R
for instance.
Create a “workload” to run
Our job will consist of a script that we want to run, we can call this our workload. This will in the real world be your scientific analysis code for instance. But in our case it will just be a simple bash script that takes no input arguments. We need to create this script first of all.
To create this script you use your text editor of choice. For instance nano
or VSCode
.
Note
Not sure what to chose? Check out our UNIX intro lesson on text editors.
Nano is a simple terminal text editor, whilst VSCode is a source code editor with inbuilt terminal and lots of extension possibilites.
Create a file named example-job.sh in your favourite text editor.
[MY_USER_NAME@CLUSTER_NAME ~]$ nano example-job.sh
The new file should have the contents below. Copy-paste this into your new file in the text editor of your choice:
#!/bin/bash
echo -n "This script is running on "
hostname
Next, from the terminal, make the file executable so that you can run the file as a script:
[MY_USER_NAME@CLUSTER_NAME ~]$ chmod +x example-job.sh
Let’s run the script from the terminal in the login node.
[MY_USER_NAME@CLUSTER_NAME ~ ]$ ./example-job.sh
This script is running on <HOSTNAME_OF_CLUSTER_LOGIN_NODE>
Discussion
What did we do now?
Did we run the job on the cluster?
What is the difference between running on a login node and running on the cluster?
Solution
We ran the example-job.sh script on the login node.
We did not run on the cluster, but on the login node. This means we did not run on the underlying computing nodes in the cluster.
The login nodes have limited capacity and are shared by everyone logged in. It is not meant to run real workloads. To run on the cluster you have to submit the job with a Slurm command such as
sbatch
- this will place the job in the Slurm queue, and the job will run once there is room for it on the compute nodes in the amount and time you requested.
So far we have created the script we want to run (our workload), but we have not yet used the Slurm system for submitting the job to the HPC clusters compute nodes. To do this, the minimum we must know is what project account to use in Slurm.
Find your project account(s)
All users on HPC clusters in Norway are part of at least one project. Each project is allocated an amount of credit. The currency used is “CPU-hours”. When you’re communicating with the scheduler, we should indicate which account should be charged.
#Most Likely your output would be different
#must you should see at least one project
[MY_USER_NAME@CLUSTER_NAME ~]$ projects
nn9970k
nn9999k
#Most Likely your output would be different
#must you should see at least one project
[MY_USER_NAME@login-4 ~]$ projects
ec01
ec11
ec12
ec34
Warning
These notes are made with the assumption that you have access to the nn9970k project as part of the onboarding course. If you do not have access to this project, you can replace it with one of the other projects you have access to. See the example above on how to find your project numbers.
Instructor note
Tricks to bypass the queue during the course:
–account=nn9970k –reservation=NRIS_onboarding_course
Submit your first Slurm job
We submit the job with the Slurm command sbatch
. The different clusters have different mandatory parameters that we have to set. They all require you to set how long the job will run for with the --time
parameter. Saga and Betzy in addition require you to set how much memory the job requires with the --mem
parameter. And finally Betzy in addition requires you to specify how many compute nodes you will run on with the --nodes
parameter.
Copy the command below (corresponding to the system you are on), paste it into your terminal, then press enter.
sbatch --account=nn9970k --mem=1G --time=01:00 example-job.sh
sbatch --account=<PROJECT_NAME> --time=01:00 example-job.sh
sbatch --account=nn9999k --time=1:00 --nodes=1 --mem=1G --partition=preproc example-job.sh
sbatch --account=<PROJECT_NAME> --mem=1G --time=01:00 example-job.sh
And that’s all we need to do to submit a job to the computing cluster. Our work is done – now the scheduler takes over and tries to run the job for us.
Check the job status
While the job is waiting to run, it goes into a list of jobs called
the queue. To check on our job’s status, we check the queue using the command
squeue -u $USER
.
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
137860 normal example- usernm R 0:02 1 c5-59
Exercise
The $USER
bash variable contains your actual username on the system you are logged into.
Use a bash command on your terminal to output the contents of this variable.
Solution
echo $USER
The best way to check our job’s status is with squeue
. Of course, running
squeue
repeatedly to check on things can be a little tiresome. To see a real-time
view of our jobs, we can use the --iterate argument
command with how frequent
should the output be refreshed.
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER --iterate 5
Warning
Press
Ctrl-C
when you want to stop the command.This test job may end before first iteration starts, if that happens we will see the output in a later job that takes more time.
Where’s the output?
Once the job is finished, you want to inspect its output. On the login node, this script printed the output to the terminal - but when we exit sbatch
, there’s nothing. Where did it go?
Cluster job output is typically redirected to a file in the directory you launched it from.
Use ls
to find and read the file.
[MY_USER_NAME@CLUSTER_NAME ~]$ ls
example-job.sh slurm-SLURM_JOB_ID.out
Where a real example of filename slurm-SLURM_JOB_ID.out
could be: slurm-14738683.out
.
Let’s open the file and inspect its contents. It could look something like this:

[maikenp@login-5.SAGA ~/hpc-intro-2025]$ cat slurm-14738683.out
Starting job 14738683 on c5-60 on saga at Wed Apr 23 16:55:27 CEST 2025
This script is running on c5-60
Job 14738683 consumed 0.0 billing hours from project nn9970k.
Submitted 2025-04-23T16:53:23; waited 2.0 minutes in the queue after becoming eligible to run.
Requested wallclock time: 60.0 seconds
Elapsed wallclock time: 1.0 seconds
Job exited normally.
Task and CPU statistics:
ID CPUs Tasks CPU util Start Elapsed Exit status
14738683 1 0.0 % 2025-04-23T16:55:26 1.0 s 0
14738683.batch 1 1 1.2 % 2025-04-23T16:55:26 1.0 s 0
Used CPU time: 0.0 CPU seconds
Unused CPU time: 1.0 CPU seconds
Memory statistics, in MiB:
ID Alloc Usage
14738683 1024.0
14738683.batch 1024.0 0.0
Job 14738683 completed at Wed Apr 23 16:55:27 CEST 2025
Note
Your Slurm output file will naturally contain a different Slurm ID than this example!
Discussion
What type of information is in the Slurm output file?
Do you know what “wallclock time” means?
Solution
There is information about
What node the job ran on
The error message from running the job script
Information about the success or failure of the job - in this case “Job exited normally” which means it succeeded.
Overview of time, cpu and memory usage
Wallclock time means how much time passed from start to end if you check on your clock - it includes any waiting time/idle time. Another time unit we use in computing is CPU-time - which is the active time the process runs on the cpu. Wallclock time can exceed cpu-time, but cpu-time can also exceed wallclock time in the case where > 1 core is used.
If a program runs for 2 minutes (wallclock time), but spends most of that time waiting for data from the disk, the CPU might only be busy for 1 minute (CPU time).
Conversely, if a parallel program uses 4 CPU cores at 100% for 2 minutes (wallclock time), the total CPU time could be 8 minutes
What if there was an error?
If there was an error of some kind, this will be recorded in the Slurm output file.
In our example let’s add the line ls hello.sh
in the end of the example-job.sh
script. Currently, there is no such file, so we expect that when the script tries to run this command there will be an error. Just try yourself on your terminal (assuming you do not have a file called hello.sh
), you will see the message: ls: hello.sh: No such file or directory
.
Exercise
Update example_job.sh by adding the line
ls hello.sh
at the end of the script.Submit the job to Slurm with sbatch
Wait for the job to run and inspect the output file
Solution
Update the file:
#!/bin/bash
echo -n "This script is running on "
hostname
ls hello.sh
Submit the job:
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch --account=<PROJECT_NAME> --mem=1G --time=01:00 example-job.sh
So what does our Slurm job output file look like after having submitted the updated script with sbatch (as before), but now having introduced the line that we expect will cause an error?

In this case we see information in the Slurm output file that the Job failed
and above that we see the cause of failure ls: cannot access 'hello.sh': No such file or directory
.
So far we have been submitting the Slurm job from the terminal manually typing the Slurm options to the sbatch
command. Once you start having more complex use-cases with more options and handling of files, maybe loading modules etc. etc., you will want to use a Slurm job script instead.
Customising a job
The job we just ran used all the scheduler’s default options. In a real-world scenario, that’s probably not what we want. The default options represent a reasonable minimum. Chances are, we will need more cores, more memory, more time, among other special considerations. To get access to these resources we must customize our job script.
Comments in UNIX shell scripts (denoted by #
) are typically ignored, but there are exceptions.
For instance the special #!
comment at the beginning of scripts specifies what program should be
used to run it (you’ll typically see #!/bin/bash
). Schedulers like SLURM also
have a special comment used to denote special scheduler-specific options. Though these comments
differ from scheduler to scheduler, SLURM’s special comment is
#SBATCH
. Anything following the #SBATCH
comment is interpreted
as an instruction to the scheduler.
Let’s illustrate this by example. By default, a job’s name is the name of the script, but the
--job-name
option can be used to change the name of a job. Add an option to the
script:
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --job-name=new_name
echo -n "This script is running on "
hostname
echo "This script has finished successfully."
sleep 60
Instructor note
What does sleep 60
mean
Submit the job (using sbatch <SLURM arguments> example-job.sh
)
and monitor it:
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
JOBID ACCOUNT NAME ST REASON START_TIME TIME TIME_LEFT NODES CPUS
38191 nn9970k new_name PD Priority N/A 0:00 1:00:00 1 1
Fantastic, we’ve successfully changed the name of our job!
Exercise
Exercise
Create a new file which will be your Slurm bash script. It should contain the parameters that we before just issued on the command line (mem
, time
, account
), but now in the #SBATCH
syntax.
Also, find out how to change the default output and error log file names.
By default this are written to the same file slurm-<JOBID>.out
- but change it to something else like for instance output-<JOBID>.txt
and error-<JOBID>.txt
.
Finally the Slurm script should execute the example-job.sh script.
Hints
Confer with e.g. ChatGPT, Google or check the man pages of
sbatch
to get help.To access the man pages for Slurm utilities from the command line, run:
man <program-name>
.[MY_USER_NAME@CLUSTER_NAME ~]$ man sbatch
You can find the same information online by searching “man sbatch” (sbatch.html).
Another very useful resource is our Job script generator
Solution
#!/bin/bash
#SBATCH --account=nn9970k
#SBATCH --mem=1GB
#SBATCH --time=1:00
#SBATCH --output=output-%j.txt
#SBATCH --error=error-%j.txt
./example-job.sh
Resource requests
But what about more important changes, such as the number of cores and memory for our jobs? One thing that is absolutely critical when working on an HPC system is specifying the resources required to run a job. This allows the scheduler to find the right time and place to schedule our job. If you do not specify requirements (such as the amount of time you need), you will likely be stuck with your site’s default resources, which is probably not what you want.
The following are several key resource requests:
Discussion
--ntasks=<ntasks>
or-n <ntasks>
: How many CPU cores does your job need, in total?--time <days-hours:minutes:seconds>
or-t <days-hours:minutes:seconds>
: How much real-world time (walltime) will your job take to run? Thepart can be omitted. --mem=<megabytes>
: How much memory on a node does your job need in megabytes? You can also specify gigabytes using by adding a little “g” afterwards (example: –mem=5g)--nodes=<nnodes>
or-N <nnodes>
: How many separate machines does your job need to run on? Note that if you set ntasks to a number greater than what one machine can offer, Slurm will set this value automatically.
Note that just requesting these resources does not make your job run faster! We’ll talk more about how to make sure that you’re using resources effectively in a later episode of this lesson.
Discussion
Discuss the commands
scontrol
sacct
Examples
Submit a job that will use 1 full node and 1 minute of walltime.
[MY_USER_NAME@CLUSTER_NAME ~ ]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1 --exclusive
#SBATCH --time=00:01:00
echo -n "This script is running on "
sleep 60 # time in seconds
hostname
echo "This script has finished successfully."
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch <Slurm arguments> example-job.sh
Print a Slurm variable. Move more arguments to the job script
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=nn9970k
#SBATCH --mem=1G
echo -n "This script is running on "
hostname
echo "This job was launched in the following directory:"
echo ${SLURM_SUBMIT_DIR}
Binding resource request
Resource requests are typically binding. If you exceed them, your job will be killed. Let’s use walltime as an example. We will request 60 seconds of walltime, and attempt to run a job for two minutes.
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=nn9970k
#SBATCH --mem=1G
#SBATCH --job-name=long_job
echo -n "This script is running on ... "
sleep 120 # time in seconds
hostname
echo "This script has finished successfully."
Submit the job and wait for it to finish. Once it has finished, check the log file.
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch example-job.sh
[MY_USER_NAME@CLUSTER_NAME ~]$ watch -n 15 squeue -u $USER
....
[MY_USER_NAME@CLUSTER_NAME ~]$ cat slurm-38193.out
This job is running on: c1-14
slurmstepd: error: *** JOB 38193 ON gra533 CANCELLED AT 2021-07-02T16:35:48
DUE TO TIME LIMIT ***
Our job was killed for exceeding the amount of resources it requested. Although this appears harsh, this is actually a feature. Strict adherence to resource requests allows the scheduler to find the best possible place for your jobs. Even more importantly, it ensures that another user cannot use more resources than they’ve been given. If another user messes up and accidentally attempts to use all the cores or memory on a node, Slurm will either restrain their job to the requested resources or kill the job outright. Other jobs on the node will be unaffected. This means that one user cannot mess up the experience of others, the only jobs affected by a mistake in scheduling will be their own.
Cancelling a job
Sometimes we’ll make a mistake and need to cancel a job. This can be done with the
scancel
command. Let’s submit a job and then cancel it using its job number (remember
to change the walltime so that it runs long enough for you to cancel it before it is killed!).
Warning
Please make sure to cancel the job you submited with the correct jobid (copy pasting the jobid in the example would not work
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=nn9970k
#SBATCH --mem=1G
#SBATCH --job-name=long_job
echo -n "Script has started ... "
sleep 300 # time in seconds
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch example-job.sh
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
Submitted batch job 38759
JOBID ACCOUNT NAME ST REASON TIME TIME_LEFT NODES CPUS
38759 nn9970k example-job.sh PD Priority 0:00 1:00 1 1
Now cancel the job with its job number (printed in your terminal). A clean return of your command prompt indicates that the request to cancel the job was successful.
[MY_USER_NAME@CLUSTER_NAME ~]$ scancel 38759
# ... Note that it might take a minute for the job to disappear from the queue ...
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
JOBID USER ACCOUNT NAME ST REASON START_TIME TIME TIME_LEFT NODES CPUS
Other types of jobs
Up to this point, we’ve focused on running jobs in batch mode. Slurm also provides the ability to start an interactive session.
There are very frequently tasks that need to be done interactively. Creating an entire job
script might be overkill, but the amount of resources required is too much for a login node to
handle. A good example of this might be building a genome index for alignment with a tool like
HISAT2. Fortunately, we can run these types of
tasks as a one-off with srun
.
Interactive jobs
Instead of running on a login node, you can ask the queue system to allocate compute resources for you, and once assigned, you can run commands interactively for as long as requested. The below is an example.
Warning
Interactive jobs require that you maintain a stable/uninterupted connection to the cluster.
There for we use terminal multiplexer like tmux
or screen
salloc --account=nn9970k --time=30:00 --nodes=1 --ntasks=1 --mem=4G
salloc --account=nn9970k --time=1:1:00 --nodes=1 --ntasks=2
salloc --account=nn9997k --time=1:1:00 --nodes=1 --ntasks=2 --mem=17G
[MY_USER_NAME@login-4 ~]$ salloc --ntasks=1 --mem-per-cpu=4G --time=00:30:00 --account=ec34
salloc: Pending job allocation 39544
salloc: job 39544 queued and waiting for resources
salloc: job 39544 has been allocated resources
salloc: Granted job allocation 39544
salloc: Waiting for resource configuration
salloc: Nodes c1-28 are ready for job
bash-4.4$ hostname
c1-28
#To end the interactive session use the command exit
bash-4.4$ exit
salloc: Relinquishing job allocation 39544
Find out available resources on a compute node
User interactive login to access a compute node and find out number of cores and amount of memory. How much of it is at your disposal ?
Solution
nproc –all
free -h
echo $SLURM_MEM_PER_NODE
echo $SLURM_NTASKS
Keeping interactive jobs alive
Interactive jobs stop when you disconnect from the login node either by
choice or by internet connection problems. To keep a job alive you can
use a terminal multiplexer like tmux
.
tmux
allows you to run processes as usual in your standard bash shell
You start tmux
on the login node before you get an interactive Slurm
session with srun
and then do all the work in it. In case of a
disconnect you simply reconnect to the login node and attach to the tmux
session again by typing:
$ tmux attach
Or in case you have multiple session running:
$ tmux list-session
$ tmux attach -t SESSION_NUMBER
As long as the tmux
session is not closed or terminated (e.g. by a
server restart) your session should continue. One problem with our
systems is that the tmux
session is bound to the particular login server
you get connected to. So if you start a tmux
session on login-1 on SAGA
and next time you get randomly connected to login-2 you first have to
connect to login-1 again by:
$ ssh login-1
To log out a tmux
session without closing it you have to press Ctrl-B
(that the Ctrl key and simultaneously “b”, which is the standard tmux
prefix) and then “d” (without the quotation marks). To close a session
just close the bash session with either Ctrl-D or type exit. You can get
a list of all tmux
commands by Ctrl-B and the ? (question mark). See
also this
page for
a short tutorial of tmux
. Otherwise, working inside a tmux
session is
almost the same as a normal bash session.