An interactive job provides the user with a login session on a compute node with the required physical resources for the period of time requested. Interactive jobs are submitted with
qsub using the
-I flag. If you do not specify your resource requirements you will be given a session with 1 core and 1 Gb of memory that will last for 1 hour.
For example, the following command will provide a login session for 1 hour on a compute node on Katana with access to a single CPU core and 8Gb memory:
z1234567@katana:~$ qsub -I -l nodes=1:ppn=1,vmem=8gb,walltime=1:00:00 qsub: waiting for job 1234.katana.science.unsw.edu.au to start qsub: job 1234.katana.science.unsw.edu.au ready z1234567@kc01b02:~$
If you want to know what resources you used when your job completes then you can add
-M firstname.lastname@example.org to your
qsub command and you will receive an email when your job completes and we have:
z1234567@katana:~$ qsub -I -l nodes=1:ppn=1,vmem=8gb,walltime=1:00:00 -M email@example.com qsub: waiting for job 1234.katana.science.unsw.edu.au to start qsub: job 1234.katana.science.unsw.edu.au ready z1234567@kc01b02:~$
The interactive job is constrained by the resources that were requested. So the previous example would be terminated after 1 hour or if a command executed within the session consumed more than 8GB memory. The job can also be terminated by the user with
CTRL-D or the
Interactive jobs can be particularly useful while developing and testing code for a future batch job, or performing an interactive analysis that requires significant compute resources. Never attempt such tasks on the head node -- submit an interactive job instead.
Like all jobs, the job scheduler will determine when an interactive job will run. There is no guarantee that an interactive job will immediately provide you with a login session on a compute node, especially when the cluster is busy. However, there is a special queue dedicated to running interactive jobs which helps to alleviate this problem. The
express queue only accepts interactive jobs and a compute node is reserved for running for these express jobs. So even when the cluster is completely busy running batch jobs, a compute node will still be available for interactive jobs. Such jobs are submitted to the
express queue with the following flags:
z1234567@katana:~$ qsub -I -q express qsub: waiting for job 1235.katana.science.unsw.edu.au to start qsub: job 1235.katana.science.unsw.edu.au ready z1234567@kc01b01:~$
In this example no specific resources were requested, so the defaults will apply. Note there is a maximum walltime limit of 2 hours, a maximum of 12 cores and 24Gb of memory for jobs submitted to the
Keeping SSH connected whilst you are running an interactive job
With all networks there is a limit to how long a connection between two computers will stay open if no data is travelling between them. This can cause problems when you are connected to Katana to run interactive jobs or even if you step away from your computer. The solution to this problem is to set the SSH keepalive variable to 60 seconds as shown in the PuTTY configuration image below.
Keeping things running while you disconnect
In order to make sure that your copy will keep running even if you are disconnected you should use the 'screen' command. To start a new screen we use the command
screen -S ID so we start a new screen by typing
firstname.lastname@example.org:~$ screen -S zID
and then you can run the commands that you usually do.
At any time you can detach the screen by typing
Control a then
Control d and log out. When you log back in you can check your progress by typing
email@example.com:~$ screen -R
to re-attach the screen.
When you are finished with the screen you can close it in the same manner that you would use to log out.
It is even possible to launch graphical applications from within interactive jobs, but this requires an X server on your local machine. On Linux or Mac establish an SSH session to the Katana head node with X11 forwarding enabled. For example:
desktop:~$ ssh -X firstname.lastname@example.org
Graphical output can then be relayed from the head node to your desktop. In addition, if an interactive job is submitted with the
-X flag then its graphical output will be relayed back to the desktop via the head node. For example, assuming an SSH connection to the head node with X11 forwarding enabled, the following commands will launch the MATLAB GUI, running on a compute node, but displayed on your own machine:
z1234567@katana:~$ qsub -I -X qsub: waiting for job 1236.katana.science.unsw.edu.au to start qsub: job 1236.katana.science.unsw.edu.au ready z1234567@kc01b02:~$ matlab
Note that X11 forwarding requires a good network connection to Katana. So this technique is only practical from machines on-campus.
If you have a Mac or Windows computer that does not have X11 installed then you will need to download and install the X2Go client. Set the host to be 'katana.science.unsw.edu.au', the session type to 'Gnome' and leave the SSH connection on port 22.