About job starters

A job starter is a specified shell script or executable program that sets up the environment for a job and then runs the job. The job starter and the job share the same environment. LSF supports three ways of running job starters: at the command, application, and queue levels. Learn how to set up and use each method.

Some jobs have to run in a particular environment, or require some type of setup to be performed before they run. In a shell environment, job setup is often written into a wrapper shell script file that itself contains a call to start the desired job.

A job starter is a specified wrapper script or executable program that typically performs environment setup for the job, then calls the job itself, which inherits the execution environment created by the job starter. LSF controls the job starter process, rather than the job. One typical use of a job starter is to customize LSF for use with specific application environments, such as Alias Renderer or IBM Rational ClearCase.

Different ways to run job starters

LSF supports three ways to run job starters: at the command level, application level, or the queue level. You can accomplish similar things with any job starter, but their functional details are slightly different:
Command level
You can run job starters from the command level in two ways:
  • As interactive jobs. In this case, use the LSF_JOB_STARTER environment variable to specify a job starter for interactive jobs submitted using the lsgrun, or ch commands. LSF_JOB_STARTER has no effect on batch jobs, including interactive batch jobs run with the bsub -I command.
  • As batch jobs and interactive jobs with the bsub -I command. In this case, set the JOB_STARTER parameter in the lsb.applications or lsb.queues files to an environment variable, so that you can use that environment variable to set your desired job starter before submitting jobs.
Application or queue levels
An LSF administrator configures application and queue level job starters; the behavior is similar between the application and queue levels, but set in their respective configuration files:
  • An administrator can configure an application with the JOB_STARTER parameter in the lsb.applications application definition file, and users submitting jobs to the specified application profile will use the configured JOB_STARTER.
  • An administrator can configure a queue with the JOB_STARTER parameter in the lsb.queues queue definition file, and users submitting jobs to the specified queue will use the configured JOB_STARTER.
If a job is submitted to an application and a queue with the JOB_STARTER parameter enabled in both, then the application-level JOB_STARTER value takes precedence.

Pre-execution commands are not job starters

A job starter differs from a pre-execution command. A pre-execution command must run successfully and exit before the LSF job starts. It can signal LSF to dispatch the job, but because the pre-execution command is an unrelated process, it does not control the job or affect the execution environment of the job. A job starter, however, is the process that LSF controls. It is responsible for invoking LSF and controls the execution environment of the job.

Examples

The following are some examples of job starters:
  • In UNIX, a job starter defined as /bin/ksh -c causes jobs to be run under a Korn shell environment.
  • In Windows, a job starter defined as C:\cmd.exe /C causes jobs to be run under a DOS shell environment.
    Note: For job starters that execute on a Windows Server 2003, x64 Edition platform, users must have read and execute privileges for cmd.exe.
  • Setting the JOB_STARTER parameter in the lsb.queues file to $USER_STARTER enables users to define their own job starters by defining the USER_STARTER environment variable.
    Restriction: USER_STARTER can only be used in UNIX clusters. Mixed or Windows-only clusters are not supported.
  • Setting a job starter to make clean causes the command make clean to be run before the user job.