Submits a job for execution and assigns it a unique numerical job ID.
Runs the job on a host that satisfies all requirements of the job, when all conditions on the job, host, queue, application profile, and cluster are satisfied. If LSF cannot run all jobs immediately, LSF scheduling policies determine the order of dispatch. Jobs are started and suspended according to the current system load.
Sets the user's execution environment for the job, including the current working directory, file creation mask, and all environment variables, and sets LSF environment variables before starting the job.
When a job is run, the command line and stdout/stderr buffers are stored in the directory home_directory/.lsbatch on the execution host. If this directory is not accessible, /tmp/.lsbtmp user_ID is used as the job's home directory. If the current working directory is under the home directory on the submission host, then the current working directory is also set to be the same relative directory under the home directory on the execution host.
By default, if the current working directory is not accessible on the execution host, LSF finds a working direction to run the job in the following order:
If the environment variable LSB_EXIT_IF_CWD_NOTEXIST is set to Y and the current working directory is not accessible on the execution host, the job exits with the exit code 2.
If no command is supplied, bsub prompts for the command from the standard input. On UNIX, the input is terminated by entering CTRL-D on a new line. On Windows, the input is terminated by entering CTRL-Z on a new line.
To kill a job submitted with bsub, use bkill.
Use bmod to modify jobs submitted with bsub. bmod takes similar options to bsub.
Jobs submitted to a chunk job queue with the following options are not chunked; they are dispatched individually:
To submit jobs from UNIX to display GUIs through Microsoft Terminal Services on Windows, submit the job with bsub and define the environment variables LSF_LOGON_DESKTOP=1 and LSB_TSJOB=1 on the UNIX host. Use tssub to submit a Terminal Services job from Windows hosts. See Using LSF on Windows for more details.
If the parameter LSB_STDOUT_DIRECT in lsf.conf is set to Y or y, and you use the -o or -oo option, the standard output of a job is written to the file you specify as the job runs. If LSB_STDOUT_DIRECT is not set, and you use -o or -oo, the standard output of a job is written to a temporary file and copied to the specified file after the job finishes. LSB_STDOUT_DIRECT is not supported on Windows.
LSF assumes that uniform user names and user ID spaces exist among all the hosts in the cluster. That is, a job submitted by a given user runs under the same user's account on the execution host. For situations where nonuniform user names and user ID spaces exist, account mapping must be used to determine the account used to run a job.
bsub uses the command name as the job name. Quotation marks are significant.
Options related to file names and job spooling directories support paths that contain up to 4094 characters for UNIX and Linux, or up to 255 characters for Windows.
Options related to command names and job names can contain up to 4094 characters for UNIX and Linux, or up to 255 characters for Windows.
Use LSF_UNIT_FOR_LIMITS in lsf.conf to specify a larger unit for the limit (MB, GB, TB, PB, or EB).
If fairshare is defined and you belong to multiple user groups, the job is scheduled under the user group that allows the quickest dispatch.
The job is not checkpointable.
bsub automatically selects an appropriate queue. If you defined a default queue list by setting LSB_DEFAULTQUEUE environment variable, the queue is selected from your list. If LSB_DEFAULTQUEUE is not defined, the queue is selected from the system default queue list specified by the LSF administrator with the DEFAULT_QUEUE parameter in lsb.params.
LSF tries to obtain resource requirement information for the job from the remote task list that is maintained by the load sharing library. If the job is not listed in the remote task list, the default resource requirement is to run the job on a host or hosts that are of the same host type as the submission host.
bsub assumes only one processor is requested.
bsub does not start a login shell but runs the job file under the execution environment from which the job was submitted.
The input file for the job is /dev/null (no input).
bsub sends mail to you when the job is done. The default destination is defined by LSB_MAILTO in lsf.conf. The mail message includes the job report, the job output (if any), and the error message (if any).
bsub charges the job to the default project. The default project is the project you define by setting the environment variable LSB_DEFAULTPROJECT. If you do not set LSB_DEFAULTPROJECT, the default project is the project specified by the LSF administrator with DEFAULT_PROJECT parameter in lsb.params. If DEFAULT_PROJECT is not defined, then LSF uses default as the default project name.
If the job is successfully submitted, displays the job ID and the queue to which the job has been submitted.
When using account mapping, the command bpeek does not work. File transfer via the -f option to bsub requires rcp to be working between the submission and execution hosts. Use the -N option to request mail, and/or the -o and -e options to specify an output file and error file, respectively.
bjobs, bkill, bqueues, bhosts, bmgroup, bmod, bchkpnt, brestart, bgadd, bgdel, bjgroup, sh, getrlimit, sbrk, libckpt.a, lsb.users, lsb.queues, lsb.params, lsb.hosts, lsb.serviceclasses, mbatchd