MjolnirDocumentation
Job Submission guide current Reviewed 2026-09-02

Interactive jobs

Sometimes you need a prompt rather than a script: testing whether a tool runs, working out the right arguments, or exploring data before committing to a batch job.

That work still belongs on a compute node. An interactive session is how you get one.

Important "Interactive" describes where you type, not where the work runs. Testing a command on the login node because it is "just a quick test" is the most common way people accidentally overload it. See Login nodes vs compute nodes.

Get a shell on a compute node#

bash
srun --partition=cpuqueue --qos=normal --nodes=1 --cpus-per-task=2 --mem-per-cpu=2G --time=01:00:00 --pty bash

What happens:

  1. Slurm queues the request like any other job.
  2. When resources are free, your prompt returns — on a compute node.
  3. Everything you type now runs there, with the resources you asked for.

Confirm where you landed:

bash
hostname

The name should differ from the login node you started on. If it has not changed, the allocation has not started yet.

Work, then release the resources#

Load software and run things exactly as you would in a script:

bash
module purge
module load samtools/1.21
samtools --version

When you are finished:

bash
exit

Warning The allocation is held until you exit or the time limit is reached — whether or not you are using it. A forgotten interactive session with a long --time occupies resources nobody else can use and counts against your fairshare. Ask for the time you need, and exit when you are done.

Choosing resources#

Keep interactive requests small and short. You are usually testing, not computing at scale, and a small request starts sooner.

--partition, --qos, --cpus-per-task, --mem-per-cpu, and --time mean the same as in a batch script — see Submitting jobs. For the partitions and QoS available and their limits, see Partitions, QoS, and fairshare.

--qos is required here exactly as it is for batch jobs.

From interactive testing to a batch job#

Interactive sessions are for working out *what* to run. Once you know, move it into a script and submit it with sbatch — batch jobs do not need you to stay connected, survive a dropped VPN, and leave a record of what was run.

Copy the module loads and commands that worked into a job script: Submitting jobs.

Note salloc is also available if you prefer to allocate resources first and then run commands into the allocation. For most interactive work the srun --pty bash form above is simpler, which is why it is shown here.