Environment

Job execution environment

By default, Platform LSF transfers environment variables from the submission to the execution host. However, some environment variables do not make sense when transferred.

How LSF sets the job execution environment

When submitting a job from a Windows to a UNIX machine, the ‑L option of bsub can be used to reinitialize the environment variables. If submitting a job from a UNIX machine to a Windows machine, you can set the environment variables explicitly in your job script.

PATH environment variable on UNIX and Windows

Platform LSF automatically resets the PATH on the execution host if the submission host is of a different type. If the submission host is Windows and the execution host is UNIX, the PATH variable is set to /bin:/usr/bin:/sbin:/usr/sbin and the path to the LSF bin directory is appended to it.

If the submission host is UNIX and the execution host is Windows, the PATH variable is set to the system PATH variable with the path to the LSF bin directory appended to it. Platform LSF looks for the presence of the WINDIR variable in the job’s environment to determine whether the job was submitted from a Windows or UNIX host. If WINDIR is present, it is assumed that the submission host was Windows; otherwise, the submission host is assumed to be a UNIX machine.

Environment variable handling on Windows

The following Windows environment variables are overridden based on the values on the execution host:

  • COMPSPEC

  • COMPUTERNAME

  • NTRESKIT

  • OS2LIBPATH

  • PROCESSOR_ARCHITECTURE

  • PROCESSOR_LEVEL

  • SYSTEMDRIVE

  • SYSTEMROOT

  • WINDIR

    If the WINDIR on the submission and execution host are different, then the system PATH variable on the execution host is used instead of that from the submission host.

    Avoid using drive names in environment variables (especially the PATH variable) for drives that are connected over the network. It is preferable to use the UNC form of the path. This is because drive maps are shared between all users logged on to a particular machine. For example, if an interactive user has drive F: mapped to \\serverX\share, then any batch job will also see drive F: mapped to \\serverX\share. However, drive F: might have been mapped to a different share on the submission host of the job.

    Job starters can be used to perform more site-specific handling of environment variables.

Control the execution environment using job starters

If running jobs on a Windows execution host, you cannot use the command bsub -L. Instead, LSF provides two job starters that apply the user environment of the execution host.

By default, the job starter executables are installed in LSF_BINDIR. If you prefer to store them elsewhere, make sure they are in a directory that is included in the default PATH on the execution host.

For example, on Windows, put the job starter under %WINDIR%.

The source code for the job starters is installed in LSF_TOP\7.0\examples.

Use either of the two following starter scripts to run jobs on a Windows execution host:
  • preservestarter:  Preserves the default user environment of the execution host; does not include any submission host settings

  • augmentstarter:  Augments the default user environment of the execution host by adding settings from the submission host that are not already defined on the execution host