bmod

Description

Modifies the options of a previously submitted job, including forwarded jobs in a MultiCluster environment. See bsub for complete descriptions of job submission options you can modify with bmod.

Only the owner of the job, the user group administrator (for jobs associated with a user group), 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, or up to 255 characters for Windows.

Options related to command names can contain up to 4094 characters for UNIX, or up to 255 characters for Window; options related to job names can contain up to 4094 characters.

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

Modifying options for a forwarded pending job are different from modifying the options of a pending job:

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. Arguments for esub executables can also be modified.

-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.

-clusters lets you modify cluster names when submitting jobs for LSF MultiCluster. bmod -clusters remote_clusters can only modify pending jobs on the submission cluster.

-cwd specifies the current working directory for a job. -cwd only works if the job is in pending state. The path can be absolute or relative to the submission directory. If the submission directory does not exist in the execution host, it tries the logical home directory. If that fails, the tmp directory is used for the CWD.

The path can include the same dynamic patterns as described for the bsub -cwd command.

-cwdn resets the value for the -cwd option to the submission directory from bsub.

If the job is submitted with -app but without -cwd, and LSB_JOB_CWD is not defined, then the application profile defined CWD will be used. If CWD is not defined in the application profile, then the DEFAULT_JOB_CWD value is used. If none of the two parameters are defined, then the submission directory will be used for CWD.

-outdir creates the output directory while the job is in pending state. This option supports the dynamic patterns for the output directory. For example, if user1 runs bmod -outdir "/scratch/joboutdir/%U/%J_%I" myjob then the system creates /scratch/joboutdir /user1/jobid_0 for the job output directory.

-outdirn resets the outdir value to the DEFAULT_JOB_OUTDIR, if defined, or sets the output directory to the submission directory where the original bsub command was running. outdir can only be modified while the job is in pending state.

-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.

If a default user group is configured (with DEFAULT_USER_GROUP in lsb.params,) bmod -Gn moves the job to the default user group. If the job is already attached to the default user group, bmod -Gn has no effect on that job. A job moved to a user group where it cannot run (without shares in a specified fairshare queue, for example) is transferred to the default user group where the job can run.

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.

-q resubmits the job to a new queue, as if it was a new submission. By default, LSF dispatches jobs in a queue in order of arrival, so the modified job goes to the last position of the new queue, no matter what its position was in the original queue.

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, only some bsub options can be modified for running jobs. You cannot make any other modifications after a job has been dispatched. You can use bmod to modify the following options for running jobs:

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.

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

bsub -R "rusage[res1=1]"

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.

bmod does not support multiple -R option strings for multi-phase rusage resource requirements.

Modified rusage consumable resource requirements for pending jobs must satisfy any limits set by the parameter RESRSV_LIMIT in lsb.queues. For running jobs, the maximums set by RESRSV_LIMIT must be satisfied but the modified rusage values can be lower than the minimum values.

Changes to multi-phase rusage strings on running jobs such as bmod -R "rusage[mem=(mem1 mem2):duration=(dur1 dur2)]" take effect immediately, and change the remainder of the current phase.

For example, a job is submitted with the following resource requirements:

bsub -R "rusage[mem=(500 300 200):duration=(20 30):decay=(1 0)]" myjob

and after 15 minutes of runtime, the following modification is issued:

bmod -R "rusage[mem=(400 300):duration=(20 10):decay=(1 0)]" job_ID

The resulting rusage string is:

rusage[mem=(400 300):duration=(20 10):decay=(1 0)]

The running job will reserve (400-((400-300)*15/20)))=325 MB memory with decay for the next (20-15)=5 minutes of runtime. The second phase will then start, reserving 300 MB of memory for the next 10 minutes with no decay, and end up with no memory reserved for the rest of the runtime.

If after 25 minutes of runtime another modification is issued:

bmod -R "rusage[mem=(200 100):duration=(20 10):decay=(1 0)]" job_ID

The job will reserve 100 MB of memory with no decay for the next 5 minutes of runtime, followed by no reserved memory for the remainder of the job.

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

For started jobs, bmod -R modifies the effective resource requirements for the job, along with the job resource usage. The effective resource requirement string for scheduled jobs represents the resource requirement used by the scheduler to make a dispatch decision. bmod -R updates the rusage part in the resource requirements, and keeps the other sections as they were in the original resource requirements. The rusage always represents the job runtime allocation, and is modified along with the job resource usage. For running jobs, you cannot change resource requirements to any of the following:

Modifying the estimated run time of jobs

Modifying job groups

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. Job groups cannot be used with resource-based SLAs that have guarantee goals.

Modifying jobs in service classes

bmod -sla Duncan 2307

attaches job 2307 to the service class Duncan.

bmod -slan 2307

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

You cannot do the following:

If a default SLA is configured (with ENABLE_EGO_DEFAULT_SLA 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.

bmod -app fluent 2308

The following command dissociates job 2308 from the service class fluent:

bmod -appn 2308

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.

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).

Modifying network scheduling options for PE jobs

The -network option modifies the network scheduling options for IBM Parallel Environment (PE) jobs. The -networkn option removes any network scheduling options for the PE job.

You cannot modify the network scheduling options for running jobs, even if LSB_MOD_ALL_JOBS=y is .

Modifying memory rusage for affinity jobs

When bmod is used to modify memory rusage of a running job with an affinity resource request, there may be inconsistencies between host-level available memory and available memory in NUMA nodes when using bhosts -l -a. This is because the modified resource requirement will take effect in the next scheduling cycle for affinity scheduling, but it will take effect immediately at the host level. bmod only updates resource usage that LSF has accounted; it has no affect on the running jobs. For memory binding, when a process has been bound to some NUMA node, LSF limits which NUMA node the process gets physical memory from. LSF does not ask the operating system to reserve any physical memory for the process.

Options

Limitations

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