Running a detachable screen process in a job
Note: the information here is old and no longer correct, retained for reference.
When you run the interactive command, you get a command prompt in the screen program.
When running the screen program in other environments, you can detach from your screen and later reattach to it. Within the environment of the interactive command, you lose this ability: Your job is terminated when you detach. (This is a design decision and not a bug.)
In case you want the best of both worlds, i.e. to be able to detach and reattach to your screen program within a job, you need to start a job in some other way and start your screen session from a separate ssh login. Here is an example of how you can do this:
$ salloc -A p2010999 -t 15:00 -p node -n 1 --qos=short --bell --no-shell salloc: Pending job allocation 204322 salloc: job 204322 queued and waiting for resources salloc: job 204322 has been allocated resources salloc: Granted job allocation 204322 $ squeue -j 204322 JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 204322 node (null) lka R 1:35 1 q4 $ xterm -e ssh -AX q4& $ xterm -e ssh -AX q4&
This salloc command gives you a job allocation of one node for 15 minutes (the "--no-shell" option is important here). Instead you can log in to any node of any of your running jobs, started with e.g. the sbatch command.
Note: in our current slurm version as of this writing (19.05), there is a bug that requires you to add a job name (-J name) if you use --no-shell.
You get a job number and from that you can find out the node name, in this example q4.
When you log in to the node with the ssh command, you can start the screen program:
$ screen
When you detach from the screen program, with e.g. the "d" command, you can later in the same ssh session or in another ssh session reattach to your screen session:
$ screen -r
When your job has terminated, you can neither reattach to your screen session nor log in to the node.
The screen session of the interactive command is integrated into your job, so e.g. all environment variables for the job is correctly assigned. For a separate ssh session, as in this example, that is not the case.
Please note that it is the job allocation that determines your core hour usage and not your ssh or screen sessions.