Administering Platform LSF - SAS

Job Execution Environment
Shared user directories
Chapter 2
How the System Works
When LSF runs your jobs, it tries to make it as transparent to the user as
possible. By default, the execution environment is maintained to be as close to
the submission environment as possible. LSF will copy the environment from
the submission host to the execution host. The execution environment
includes the following:
◆ Environment variables needed by the job
◆ Working directory where the job begins running
◆ Other system-dependent environment settings; for example, resource
usage limits and umask:
Since a network can be heterogeneous, it is often impossible or undesirable to
reproduce the submission host’s execution environment on the execution host.
For example, if home directory is not shared between submission and
execution host, LSF runs the job in the /tmp on the execution host. If the
DISPLAY environment variable is something like Unix:0.0, or :0.0, then it
must be processed before using on the execution host. These are automatically
handled by LSF.
To change the default execution environment, use:
◆ A job starter
◆ bsub -L
For resource control, LSF also changes some of the execution environment of
jobs. These include nice values, resource usage limits, or any other
environment by configuring a job starter.
LSF works best when user home directories are shared across all hosts in the
cluster. To provide transparent remote execution, you should share user home
directories on all LSF hosts.
To provide transparent remote execution, LSF commands determine the user’s
current working directory and use that directory on the remote host.
For example, if the command cc file.c is executed remotely, cc only finds
the correct file.c if the remote command runs in the same directory.
LSF automatically creates an .lsbatch subdirectory in the user’s home
directory on the execution host. This directory is used to store temporary input
and output files for jobs.
Administering Platform LSF 49