bmod

modifies job submission options of a job

Synopsis

bmod [bsub_options] [job_ID | "job_ID[index]"]
bmod [-g job_group_name | -gn] [job_ID]
bmod [-sla service_class_name | -slan] [job_ID]
bmod [-aps "system=value" | "admin=value" | -apsn] [job_ID]
bmod [-h | -V]

Option List

[-ar | -arn]
[-B | -Bn]
[-N | -Nn]
[-r | -rn]
[-ul | -uln]
[-x | -xn]
[-a esub_application]
[-app application_profile_name | -appn]
[-aps "system=value" | "admin=value" | -apsn]
[-b begin_time | -bn]
[-C core_limit | -Cn]
[-c [hour:]minute[/host_name | /host_model] | -cn]
[-cwd "current_working_directory" | -cwdn]
[-D data_limit | -Dn]
[-E "pre_exec_command [argument ...]" | -En]
[-Ep "post_exec_command [argument ...]" | -Epn]
[-e err_file | -en]
[-eo err_file | -en]
[-ext[sched] "external_scheduler_options"]
[-F file_limit | -Fn]
[-f "local_file op [remote_file]" ... | -fn]
[-G user_group | -Gn]
[-g job_group_name | -gn]
[-i input_file | -in | -is input_file | -isn]
[-J job_name | -J "%job_limit" | -Jn]
-k "checkpoint_dir [init=initial_checkpoint_period] [checkpoint_period]" | -kn]
[-L login_shell | -Ln]
[-Lp ls_project_name | -Lpn]
[-M mem_limit | -Mn]
[-m "host_name[@cluster_name][[!] | +[pref_level]] | host_group[[!] | +[pref_level]| compute_unit[[!] | +[pref_level]] ..." | -mn]
[-mig migration_threshold | -mign]
[-n num_processors | -nn ]
[-o out_file | -on]
[-oo out_file | -oon]
[-P project_name | -Pn]
[-p process_limit | -pn]
[-Q "[exit_code …] [EXCLUDE(exit_code)]" ]
[-q "queue_name ..." | -qn]
[-R "res_req" [-R "res_req" …] | -Rn]
[-rnc resize_notification_cmd | -rncn ]
[-S stack_limit | -Sn]
[-s signal | -sn]
[-sla service_class_name | -slan]
[-sp priority | -spn]
[-T thread_limit | -Tn]
[-t term_time | -tn]
[-U reservation_ID | -Un]
[-u mail_user | -un]
[-v swap_limit | -vn]
[-W [hour:]minute[/host_name | /host_model] | -Wn]
[-We [hour:]minute[/host_name | /host_model] | -Wep [value] | -We+ [hour:]minute] | -Wen]
[-w 'dependency_expression' | -wn]
[-wa '[signal | command | CHKPNT]' | -wan]
[-wt 'job_warning_time' | -wtn]
[-Z "new_command" | -Zs "new_command" | -Zsn]
[job_ID | "job_ID[index]"]

Description

Modifies the options of a previously submitted job. See bsub for complete descriptions of job submission options you can modify with bmod.

Only the owner of the job, or LSF administrators, can modify the options of a job.

All options specified at submission time may be changed. The value for each option may be overridden with a new value by specifying the option as in bsub. To reset an option to its default value, use the option string followed by 'n'. Do not specify an option value when resetting an option.

The -i, -in, and -Z options have counterparts that support spooling of input and job command files (-is, -isn, -Zs, and -Zsn).

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.

You can modify all options of a pending job, even if the corresponding bsub option was not specified.

Modifying a job that is pending in a chunk job queue (CHUNK_JOB_SIZE) removes the job from the chunk to be scheduled later.

Like bsub, bmod calls the master esub (mesub), which invokes any mandatory esub executables configured by an LSF administrator, and any executable named esub (without .application) if it exists in LSF_SERVERDIR. Only esub executables invoked by bsub can change the job environment on the submission host. An esub invoked by bmod cannot change the job environment.

-b modifies the job begin time. If the year field is specified and the specified time is in the past, the start time condition is considered reached and LSF dispatches the job if slots are available.

-t modifies job termination time. If the year field is specified and the specified time is in the past, the job modification request is rejected.

-cwdn sets the current working directory for the job to the directory where bmod is running.

-Epn cancels the setting of job-level post-execution commands. The job-level post-execution commands do not run. Application-level post-execution commands run if they exist.

For resizable jobs, bmod -R "rusage[mem | swp]" only affects the resize allocation request if the job has not been dispatched.

-m modifies the first execution host list. When used with a compound resource requirement, the first host allocated must satisfy the simple resource requirement string appearing first in the compound resource requirement.

-rn resets the rerunnable job setting specified by bsub –rn or bsub -r. The application profile and queue level rerunnable job setting if any is used. bmod -rn does not disable or override job rerun if the job was submitted to a rerunnable queue or application profile with job rerun configured. bmod –rn is different from bsub -rn, which does override the application profile and queue level rerunnable job setting.

-uln sets the user shell limits for pending jobs to their default values. -uln is not supported on Windows.

-Wen cancels the estimated job runtime. The runtime estimate does not take effect for the job.

-Q does not affect running jobs. For rerunnable and requeue jobs, -Q affects the next run.

Modifying running jobs

By default, you can modify resource requirements for running jobs (-R "res_req" except -R "cu[cu_string]") and the estimated running time for running or suspended jobs (-We, -We+, -Wep). To modify additional job options for running jobs, define LSB_MOD_ALL_JOBS=Y in lsf.conf.

When LSB_MOD_ALL_JOBS=Y is set, the following are the only bmod options that are valid for running jobs. You cannot make any other modifications after a job has been dispatched.

  • CPU limit (-c [hour:]minute[/host_name | /host_model])

  • Memory limit (-M mem_limit)

  • Rerunnable jobs (-r | -rn)

  • Resource requirements (-R "res_req" except -R "cu[cu_string]")

  • Run limit (-W run_limit[/host_name | /host_model])

  • Standard output (stdout) file name up to 4094 characters for UNIX and Linux or 255 characters for Windows (-o output_file)

  • Standard error (stderr) file name up to 4094 characters for UNIX and Linux or 255 characters for Windows (-e error_file)

  • Overwrite standard output (stdout) file name up to 4094 characters for UNIX and Linux or 255 characters for Windows (-oo output_file)

  • Overwrite standard error (stderr) file name up to 4094 characters for UNIX and Linux or 255 characters for Windows (-eo error_file)

Modified resource usage limits cannot exceed limits defined in the queue.

To modify the CPU limit or the memory limit of running jobs, the parameters LSB_JOB_CPULIMIT=Y and LSB_JOB_MEMLIMIT=Y must be defined in lsf.conf.

If you want to specify array dependency by array name, set JOB_DEP_LAST_SUB in lsb.params. If you do not have this parameter set, the job is rejected if one of your previous arrays has the same name but a different index.

By default, options for the following resource usage limits are specified in KB:
  • Core limit (-C)

  • Memory limit (-M)

  • Stack limit (-S)

  • Swap limit (-v)

Use LSF_UNIT_FOR_LIMITS in lsf.conf to specify a different unit for the limit (MB, GB, TB, PB, or EB).

Modifying resource requirements

The -R option of bmod completely replaces any previous resource requirement specification. It does not add the modification to the existing specification. For example, if you submit a job with
bsub -R "rusage[res1=1]"
then modify it with
bmod -R "rusage[res2=1]"

the new resource usage requirement for the job is [res2=1], not [res1=1; res2=1].

bmod does not support the OR (||) operator on the -R option.

To remove all of the string input specified using the bsub command, use the -Rn option.

Modifying the estimated run time of jobs

The following options allow you to modify a job’s estimated run time:
  • -We [hour:]minute[/host_name | /host_model]: Sets an estimated run time. Specifying a host or host model normalizes the time with the CPU factor (time/CPU factor) of the host or model.

  • -We+ [hour:]minute]: Sets an estimated run time that is the value you specify added to the accumulated run time. For example, if you specify -We+ 30 and the job has already run for 60 minutes, the new estimated run time is now 90 minutes.

    Specifying a host or host model normalizes the time with the CPU factor (time/CPU factor) of the host or model.

  • -Wep [value]: Sets an estimated run time that is the percentage of job completion that you specify added to the accumulated run time. For example, if you specify -Wep+ 25 (meaning that the job is 25% complete) and the job has already run for 60 minutes, the new estimated run time is now 240 minutes.

    The range of valid values is greater than 0 and less than or equal to 100. Two digits after decimal are supported.

    Specifying a host or host model normalizes the time with the CPU factor of the host or model (time/CPU factor).

Modifying job groups

Use the -g option of bmod and specify a job group path to move a job or a job array from one job group to another. For example:
bmod -g /risk_group/portfolio2/monthly 105

moves job 105 to job group /risk_group/portfolio2/monthly.

Like bsub -g, if the job group does not exist, LSF creates it.

bmod -g cannot be combined with other bmod options. It can only operate on pending jobs. It cannot operate on running or finished jobs.

You can modify your own job groups and job groups that other users create under your job groups. LSF administrators can modify job groups of all users.

You cannot move job array elements from one job group to another, only entire job arrays. If any job array elements in a job array are running, you cannot move the job array to another group. A job array can only belong to one job group at a time.

You cannot modify the job group of a job attached to a service class.

Modifying jobs in service classes

The -sla option modifies a job by attaching it to the specified service class. The -slan option detaches the specified job from a service class. If the service class does not exist, the job is not modified. For example:
bmod -sla Kyuquot 2307

attaches job 2307 to the service class Kyuquot.

bmod -slan 2307

detaches job 2307 from the service class Kyuquot. If a default SLA is configured in lsb.params, the job is moved to the default service class.

You cannot

  • Use -sla with other bmod options

  • Move job array elements from one service class to another, only entire job arrays

  • Modify the service class of job already attached to a job group. Use bsla to display the configuration properties of service classes configured in lsb.serviceclasses, the default SLA configured in lsb.params, and dynamic information about the state of each service class.

If a default SLA is configured in lsb.params, bmod -slan moves the job to the default SLA. If the job is already attached to the default SLA, bmod -slan has no effect on that job.

Modifying jobs associated with application profiles

The -app option modifies a job by associating it to the specified application profile. The -appn option dissociates the specified job from its application profile. If the application profile does not exist, the job is not modified.

You can only modify the application profile for pending jobs. For example:
bmod -app fluent 2308

associates job 2308 with the application profile fluent.

bmod -appn 2308

dissociates job 2308 from the service class fluent.

Use bapp to display the properties of application profiles configured in LSB_CONFDIR/cluster_name/configdir/lsb.applications.

Modifying absolute priority scheduling options

Administrators can use bmod -aps to adjust the APS value for pending jobs. bmod -apsn cancels previous bmod -aps settings. You cannot combing bmod -aps with other bmod options.

You can only change the APS value for pending resizable jobs.

-aps "system=value" job_ID

Set a static non-zero APS value of a pending job. Setting a system APS value overrides any calculated APS value for the job. The system APS value cannot be applied to running jobs.

-aps "admin=value" job_ID

Set a non-zero ADMIN factor value for a pending job. The ADMIN factor adjusts the calculated APS value higher or lower. A negative admin value is lowers the calculated APS value, and a positive value raises the calculated APS value relative to other pending jobs in the APS queue.

You cannot configure APS weight, limit, or grace period for the ADMIN factor. The ADMIN factor takes effect as soon as it is set.

-apsn

Run bmod -apsn to cancel previous bmod -aps settings. You cannot apply bmod -apsn on running jobs in an APS queue. An error is issued if the job has no system APS priority or ADMIN factor set.

Modifying resizable jobs

Use the -rnc and -ar options to modify the autoresizable attribute or resize notification command for resizable jobs. You can only modify the autoresizable attribute for pending jobs (PSUSP or PEND). You can only modify the resize notification command for unfinished jobs (not DONE or EXIT jobs).

-rnc resize_notification_cmd

Specify the name of an executable to be invoked on the first execution host when the job allocation has been modified (both shrink and grow). bmod -rnc overrides any notification command specified in the application profile.

-rncn

Remove the notification command setting from the job.

-ar

Specify that the job is autoresizable.

-arn

Remove job-level autoresizable attribute from the job.

Options

job_ID | "job_ID[index]"

Modifies jobs with the specified job ID.

Modifies job array elements specified by "job_ID[index]".

-h

Prints command usage to stderr and exits.

-V

Prints LSF release version to stderr and exits.

Limitations

Modifying remote running jobs in a MultiCluster environment is not supported.

If you do not specify -e or -eo before the job is dispatched, you cannot modify the name of job error file for a running job. Modifying the job output options of remote running jobs is not supported.

See also

bsub