LSF Version 7.3 - Administering Platform LSF

Administering Platform LSF 565
Pre-Execution and Post-Execution Commands
Setting a pre- and post-execution user ID
By default, both the pre- and post-execution commands are run as the job
submission user. Use the LSB_PRE_POST_EXEC_USER parameter in
lsf.sudoers to specify a different user ID for queue-level and application-level
pre- and post-execution commands.
Example If the pre- or post-execution commands perform privileged operations that require
root permission, specify:
LSB_PRE_POST_EXEC_USER=root
See the Platform LSF Configuration Reference for information about the
lsf.sudoers file.
Including job post-execution in job finish status reporting
By default, LSF releases resources for a job as soon as the job is finished and when
sbatchd reports job finish status (DONE or EXIT) to mbatchd. Post-execution
processing is not considered part of job processing. This makes it possible for a new
job to be started before post-execution processing for a previous job is complete.
There are situations where you do not want the first job’s post-execution affecting
the second job’s execution. Or the execution of a second job might crucially depend
on the completion of post-execution of the previous job.
In other cases, you may want to include job post-execution in job accounting
processes, or if the post-exacerbation is CPU intensive, you might not want a
second job running at the same time. Finally, system configuration required by the
original job may be changed or removed by a new job, which could prevent the first
job from finishing normally.
To enable all associated processing to complete before LSF reports job finish status,
configure JOB_INCLUDE_POSTPROC=Y in an application profile in
lsb.applications or cluster wide in lsb.params.
When JOB_INCLUDE_POSTPROC is set:
◆ sbatchd sends both job finish status (DONE or EXIT) and post-execution
status (POST_DONE or POST_ERR) to
mbatchd at the same time
◆ The job remains in RUN state and holds its job slot until the job post-execution
processing has finished
◆ Jobs can now depend on the completion of post-execution processing
◆ bjobs, bhist, and bacct will show the same time for both job finish and
post-execution finish
◆ Job requeue will happen after post-execution processing, not when the job
finishes
For job history and job accounting, the job CPU time and run time will also include
the post-execution CPU time and run time.
Limitations and
side-effects
Job query commands (bjobs, bhist) show that the job remains in RUN state until
the post-execution processing is finished, even though the job itself has finished.
job control commands (
bstop, bkill, bresume) will have no effect.