Econlab

Running Applications in the Background

This document describes how to run your statistical applications and processes in the background, so that large programs will continue to run when you have logged off the server.

The easiest way to initiate processes which you plan to execute in the background is to avoid using Xwindows. Simply login to the Athens server using an SSH client without using XWin32 and run the program in batch mode. The key commands that you will need to use are 'nohup' (no hangup) command and the ampersand, '&', which instructs processes to run in the background.

Alternatively you can use the screen command to disconnect and reconnect to an active SSH session. Type "man screen" for instructions on running this command. As well you can run a full graphical session via VNC which you can connect and disconnect from. Instructions for running VNC can be found here.



*One thing to remember when executing a script in the background is to always specify an output file for the results. (The default is to print results to the screen, which won't do any good if you're not there to see them.)

Here are some examples for each application:

SPSS

To run a detached process in SPSS (one which will not terminate when you logoff) us the 'nohup' command with the ampersand, '&'.

nohup spss file1.sps >file2.lst 2>file3.err &

This command will execute your syntax file (file1.sps) as a detached process, storing the output of your program in file2.lst and logging any error messages to file3.err.

It is also possible to schedule a process to execute at a specified time by using the 'at' command. For example:

at 9pm spss file1.sps >file2.lst 2>file3.err &

SAS

The nohupcommand and &can also be used to execute SAS programs as detached processes:

nohup sas myprog.sas >myprog.out &

Similarly, to schedule a process at some time in the future:

at 9pm sas myprog.sas >myprog.out &

Stata

Running a Stata program in the background requires slightly different syntax, since we need the '-b' to indicate batch mode.

nohup stata -b do myfile &

(It is also possible to do 'nohup stata &#60prog.do >outputfile &', but this is not recommended because 1) the Stata program will not know that this is executing as a batch process and may pause for silly reasons and 2) the logfile myfile.log will not automatically be created, as it will with the command above.)

And we can also use the 'at' command:

at 9pm stata -b do myfile &

Matlab

To run a Matlab program in the background, the syntax is:

nohup matlab <myprog.m >myprog.out &

Or to schedule a later process:

at 9pm matlab <myprog.m >myprog.out &

S-Plus

Running S-Plus in the background also requires that we indicate batch mode, which in this case we do with the 'BATCH' flag. For example:

nohup splus BATCH infile.s outfile &

And for scheduled jobs:

at 9pm splus BATCH infile.s outfile &

R

Background processes in R are initiated the same as in S-Plus:

nohup R CMD BATCH infile outfile &

And for scheduled jobs:

at 9pm R CMD BATCH infile outfile &

Checking your jobs

In order to see which jobs are currently running, type 'ps'. This will display all the active processes associated with the current terminal. The output contains the process ID (PID), cumulative execution time, and the command name. Typing 'ps -elf' will display all the processes on the current machine. Typing 'ps -u username' will display all the processes belonging to that user on the current machine. If you decide that you no longer want to execute one of your processes, you can type 'kill PID', where PID is the process ID identified by the 'ps' command.

Niceness

When running large batch jobs, you should also be aware that to prevent runaway jobs and to be fair to all users the system has a processor quota. This means that each user on the system is allocated one hour of highest priority CPU time each day. What does this mean for your programs? After you have run one CPU hour of programs in one day, any further processing you do will be re-niced, to a lower priority. So if another user runs a program, their process will be executed first then you process will be run. In short, your programs will continue to run as the would after you have used your daily quota but if there are many users on the system then your program might run somewhat slower.
If you have any questions about this or you would like to purchase a higher processor quota please contact ssc-server-support@listhost.uchicago.edu