Detachable login sessions

Students

Students have access to public lab rooms and shell servers, but neither should be used for long-running computations.

• Lab room computers can only be used locally, not remotely.
• Lab room computers should not be left unattended (with screen locked) for more than 15 minutes.
• Shell servers have restricted resources, and you should take care so your jobs do not affect other users.

But there are computation servers available. Ask your course leader (or supervisor) to contact us for access.

Employees (faculty and staff)

Many employees have personal workstations, that can usually be accessed remotely (using ssh). Many departments also run dedicated computation servers or resource machine, that you can get access to.

Rather than having an application connected to a graphical session (and locking the screen), you can set up a detachable session. This way programs can also read and write to your AFS home directory. (For this an application must have valid AFS tokens, which can expire and are lost when your login session exits.)

You may also be able to use /NOBACKUP, more details below.

Detachable sessions

You will need to combine a set of tools:

• Use kpagsh to set up a credentials sandbox (Process Authentication Group, PAG) for Kerberos tickets and AFS tokens.
• Use kinit to get tickets inside the sandbox, and automatically renew them.
• Use screen to get a detachable shell session.

This can all be done in a single command:

kpagsh kinit -l 1d -r 1w username@KTH.SE screen -D -m

Note: screen will launch in non-detached mode (so kinit can ask for your password). You must then use Ctrl-z bg to detach it, and reconnect with screen -r.

kinit will automatically renew tickets when they expire. If you want to keep track of remaining time, launch a new window in the screen session, and do klist -Tf. If you re-run klist a day or so later, you will see new timestamps for the ticket-granting-ticket, krbtgt/KTH.SE@KTH.SE. See the kinit man page (external link)  for details.

You can then start your job inside the screen session. See GNU Screen on Wikipedia (external link)  for more information.

Other options

Store temporary data in /NOBACKUP

On a personal workstation, and some computational servers, you can store data in /NOBACKUP/username, a directory on the local hard disk. Accessing local disk is much faster than network storage, and do not require AFS tickets.

But as the name implies, no backup is made of these files. So only use it for files that can be re-created from git, cloud storage, etc., or for temporary storage of work files that you later copy elsewhere!

On shared systems: Available disk space is shared among all users, so please make sure to clear out old files from your /NOBACKUP directory.

Run in non-graphical mode in screen session

Note that you can run programs such as MatlabⓇ in non-graphical mode:

nohup

If your program does not require a terminal, you can run it directly rather than using screen. You may need to use nohup to prevent it from being killed when you log out. Please make sure the command exits! If it does not, you must make sure to manually kill the job (using e.g. its PID). Otherwise it may block patching (reboots) of your workstation, or a server used by others at your department.

Job scheduling for batch jobs

Most shell servers do not have any job scheduler (for batch job scheduling), since there is no consensus on which one to use.

Application checkpointing

By structuring your program to use application checkpointing , you may be able to halt or pause jobs without losing data.