|Knowledge Center Contents Previous Next Index|
Running Interactive and Remote Tasks
This chapter provides instructions for running tasks interactively and remotely with non-batch utilities such as
- Running Remote Tasks
- Interactive Tasks
- Load Sharing Interactive Sessions
- Load Sharing X Applications
Running Remote Tasks
lsrunis a non-batch utility to run tasks on a remote host.
lsgrunis a non-batch utility to run the same task on many hosts, in sequence one after the other, or in parallel.
The default for
lsrunis to run the job on the host with the least CPU load (represented by the lowest normalized CPU run queue length) and the most available memory. Command-line arguments can be used to select other resource requirements or to specify the execution host.
To avoid typing in the
lsruncommand every time you want to execute a remote job, you can also use a shell alias or script to run your job.
For a complete description of
lsgrunoptions, see the
In this section
- Run a task on the best available host
- Run a task on a host with specific resources
- Run a task on a specific host
- Run a task by using a pseudo-terminal
- Run the same task on many hosts in sequence
- Run parallel tasks
- Run tasks on hosts specified by a file
Run a task on the best available host
- To run
mytaskon the best available host, enter:
LSF automatically selects a host of the same type as the local host, if one is available. By default the host with the lowest CPU and memory load is selected.
Run a task on a host with specific resources
If you want to run
mytaskon a host that meets specific resource requirements, you can specify the resource requirements using the
lsrun -R 'cserver && swp>100' mytask
In this example
mytaskmust be run on a host that has the resource
cserverand at least 100 MB of virtual memory available.
You can also configure LSF to store the resource requirements of specific tasks. If you configure LSF with the resource requirements of your task, you do not need to specify the
lsrunon the command-line. If you do specify resource requirements on the command line, they override the configured resource requirements.
Platform LSF Configuration Referencefor information about configuring resource requirements in the
Resource reservation is only available for batch jobs. If you run jobs using only LSF Base, LIM uses resource usage to determine the placement of jobs. Resource usage requests are used to temporarily increase the load so that a host is not overloaded. When LIM makes a placement advice, external load indices are not considered in the resource usage string. In this case, the syntax of the resource usage string isres[=value]:res[=value]: ... :res[=value]
resis one of the resources whose value is returned by the lsload command.rusage[r1m=0.5:mem=20:swp=40]
The above example indicates that the task is expected to increase the 1-minute run queue length by 0.5, consume 20 MB of memory and 40 MB of swap space.
If no value is specified, the task is assumed to be intensive in using that resource. In this case no more than one task will be assigned to a host regardless of how many CPUs it has.
The default resource usage for a task is
r15s=1.0:r1m=1.0:r15m=1.0. This indicates a CPU-intensive task which consumes few other resources.
Run a task on a specific host
- If you want to run your task on a particular host, use the
lsrun -m hostD mytask
Run a task by using a pseudo-terminal
Submission of interaction jobs using pseudo-terminal is not supported for Windows for either
Some tasks, such as text editors, require special terminal handling. These tasks must be run using a pseudo-terminal so that special terminal handling can be used over the network.
lsrunspecifies that the job should be run using a pseudo-terminal:
lsrun -P vi
Run the same task on many hosts in sequence
lsgruncommand allows you to run the same task on many hosts, one after the other, or in parallel.
- For example, to merge the
/tmp/outfile on hosts
hostBinto a single file named
lsgrun -m "hostA hostD hostB" cat /tmp/out >> gout
Run parallel tasks
lsgrunthat the task specified should be run in parallel. See
lsgrun(1)for more details.
- To remove the
/tmp/corefile from all 3 hosts, enter:
lsgrun -m "hostA hostD hostB" -p rm -r /tmp/core
Run tasks on hosts specified by a file
host_fileoption reads the
host_filefile to get a list of hosts on which to run the task.
LSF supports transparent execution of tasks on all server hosts in the cluster. You can run your program on the best available host and interact with it just as if it were running directly on your workstation. Keyboard signals such as
CTRL-Cwork as expected.
Interactive tasks communicate with the user in real time. Programs like
viuse a text-based terminal interface. Computer Aided Design and desktop publishing applications usually use a graphic user interface (GUI).
This section outlines issues for running interactive tasks with the non-batch utilities
lsgrun, etc. To run interactive tasks with these utilities, use the
For more details, see the
In this section
- Interactive tasks on remote hosts
- Interactive processing and scheduling policies
- Shared files and user IDs
- Shell mode for remote execution
- Run windows
- Redirect streams to files
Interactive tasks on remote hosts
When you run an interactive task on a remote host, you can perform most of the job controls as if it were running locally. If your shell supports job control, you can suspend and resume the task and bring the task to background or foreground as if it were a local task.
For a complete description, see the
Hiding remote execution
You can also write one-line shell scripts or
cshaliases to hide remote execution. For example:#!/bin/sh # Script to remotely execute mytask exec lsrun -m hostD mytask
alias mytask "lsrun -m hostD mytask"
Interactive processing and scheduling policies
LSF lets you run interactive tasks on any computer on the network, using your own terminal or workstation. Interactive tasks run immediately and normally require some input through a text-based or graphical user interface. All the input and output is transparently sent between the local host and the job execution host.
Shared files and user IDs
When LSF runs a task on a remote host, the task uses standard UNIX system calls to access files and devices. The user must have an account on the remote host. All operations on the remote host are done with the user's access permissions.
Tasks that read and write files access the files on the remote host. For load sharing to be transparent, your files should be available on all hosts in the cluster using a file sharing mechanism such as NFS or AFS. When your files are available on all hosts in the cluster, you can run your tasks on any host without worrying about how your task will access files.
LSF can operate correctly in cases where these conditions are not met, but the results may not be what you expect. For example, the
/tmpdirectory is usually private on each host. If you copy a file into
/tmpon a remote host, you can only read that file on the same remote host.
LSF can also be used when files are not available on all hosts. LSF provides the
lsrcpcommand to copy files across LSF hosts. You can use pipes to redirect the standard input and output of remote commands, or write scripts to copy the data files to the execution host.
Shell mode for remote execution
On UNIX, shell mode support is provided for running interactive applications through RES.
Not supported for Windows.
Shell mode support is required for running interactive shells or applications that redefine the
CTRL-Zkeys (for example,
lsgruncreates the remote task with shell mode support. The default is not to enable shell mode support.
Some run windows are only applicable to batch jobs. Interactive jobs scheduled by LIM are controlled by another set of run windows.
Redirect streams to files
By default, both standard error messages and standard output messages of interactive tasks are written to
stdouton the submission host.
stderrand redirect to separate files, set LSF_INTERACTIVE_STDERR=y in
lsf.confor as an environment variable.
- To redirect both
stderrto different files with the parameter set:
lsrun mytask 2>mystderr 1>mystdout
The result of the above example is for
stderrto be redirected to
mystdout. Without LSF_INTERACTIVE_STDERR set, both
stdoutwill be redirected to
Platform LSF Configuration Referencefor more details on LSF_INTERACTIVE_STDERR.
Load Sharing Interactive Sessions
There are different ways to use LSF to start an interactive session on the best available host.
Log on to the least loaded host
- To log on to the least loaded host, use the
When you use
lslogin, LSF automatically chooses the best host and does an
rloginto that host.
With no argument,
lsloginpicks a host that is lightly loaded in CPU, has few login sessions, and whose binary is compatible with the current host.
Log on to a host with specific resources
- If you want to log on a host that meets specific resource requirements, use the
lslogin -R res_reqoption.
lslogin -R "solaris order[ls:cpu]"
This command opens a remote login to a host that has the
sunosresource, few other users logged in, and a low CPU load level. This is equivalent to using
lsplaceto find the best host and then using
rloginto log in to that host:
rlogin 'lsplace -R "sunos order[ls:cpu]"'
Load Sharing X Applications
Start an xterm
- If you are using the X Window System, you can start an
xtermthat opens a shell session on the least loaded host by entering:
lsrun sh -c xterm &
&in this command line is important as it frees resources on the host once
xtermis running, by running the X terminal in the background.
In this example, no processes are left running on the local host. The
lsruncommand exits as soon as
xtermstarts, and the
xtermon the remote host connects directly to the X server on the local host.
xterm on a PC
Each X application makes a separate network connection to the X display on the user's desktop. The application generally gets the information about the display from the DISPLAY environment variable.
X-based systems such as
eXceedstart applications by making a remote shell connection to the UNIX server, setting the DISPLAY environment variable, and then invoking the X application. Once the application starts, it makes its own connection to the display and the initial remote shell is no longer needed.
This approach can be extended to allow load sharing of remote applications. The client software running on the X display host makes a remote shell connection to any server host in the LSF cluster. Instead of running the X application directly, the client invokes a script that uses LSF to select the best available host and starts the application on that host. Because the application then makes a direct connection to the display, all of the intermediate connections can be closed. The client software on the display host must select a host in the cluster to start the connection. You can choose an arbitrary host for this; once LSF selects the best host and starts the X application there, the initial host is no longer involved. There is no ongoing load on the initial host.
Setting up an X terminal to start an X session on the least loaded host
If you are using a PC as a desktop machine and are running an X Window server on your PC, then you can start an X session on the least loaded host.
The following steps assume you are using
Exceedfrom Hummingbird Communications. This procedure can be used to load share any X-based application.
You can customize host selection by changing the resource requirements specified with
-R "...".For example, a user could have several icons in the
xtermprogram group: one called
Best, another called
Set up Exceed to log on the least loaded host
To set up
Exceedto log on to the least loaded host:
- Click the Xstart icon in the Exceed program group.
- Choose REXEC (TCP/IP, ...) as start method, program type is X window.
- Set the host to be any server host in your LSF cluster:
lsrun -R "type==any order[cpu:mem:login]" xterm -sb -ls -display
- Set description to be Best.
- Click the Install button in the Xstart window.
Bestas an icon in the program group you chose (for example,
The user can now log on to the best host by clicking Best in the Xterm program group.
Start an xterm in Exceed
To start an
- Double-click the Best icon.
xtermstarts on the least loaded host in the cluster and is displayed on your screen.
Running any application on the least loaded host
appYon the best machine licensed for it, you could set the command line in
Exceedto be the following and set the description to
lsrun -R "type==any && appY order[mem:cpu]" sh -c "appY -display
You must make sure that all the UNIX servers licensed for
appYare configured with the resource "
appY". In this example,
appYrequires a lot of memory when there are embedded graphics, so we make "
mem" the most important consideration in selecting the best host among the eligible servers.
Starting an X session on the least loaded host in any X desktop environment
The above approach also applies to other X desktop environments. In general, if you want to start an X session on the best host, run the following on an LSF host:
lsrun -R "
" my_Xapp -display
resource_requirementis your resource requirement string
Script for automatically specifying resource requirements
The above examples require the specification of resource requirement strings by users. You may want to centralize this such that all users use the same resource specifications.
You can create a central script (for example
lslaunch) and place it in the
/lsf/bindirectory. For example:#!/bin/sh lsrun -R "order[cpu:mem:login]" $@ exit $?
Which would simplify the command string to:lslaunch xterm -sb -ls -display your_PC:0.0
Taking this one step further, you could create a script named
lsxterm:#!/bin/sh lsrun -R "order[cpu:mem:login]" xterm -sb -ls $@ exit $?
Which would simplify the command string to:lsxterm -display
Platform Computing Inc.
|Knowledge Center Contents Previous Next Index|