Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lsf-drmaa forces SUB_NOTIFY_END when output_path is set unless undocumented prepand_report configuration option is set #4

Open
jrandall opened this issue Mar 22, 2015 · 5 comments
Labels
unverified This bug has not been verified by developers

Comments

@jrandall
Copy link

We have spent the past few days tracking down an issue in which LSF-DRMAA wasn't working on our cluster. In our cluster, bsub -N and bsub -B are disabled, and so trying to submit a job with SUB_NOTIFY_BEGIN or SUB_NOTIFY_END options set results in a failure.

We have finally tracked the issue down to lsf-drmaa. The hint was that we are able to submit jobs as long as output_path is not set. If, however, output_path is set (i.e. by calling setOutputPath()), then the job submissions fail.

The code at fault appears to be: https://github.com/PlatformLSF/lsf-drmaa/blob/master/lsf_drmaa/job.c#L833-841

I'm not sure what the intention of this code block is, but the end result it that if the conditions are met, it sets the SUB_NOTIFY_END option (even if DRMAA_BLOCK_EMAIL is set and resulted in the block before (https://github.com/PlatformLSF/lsf-drmaa/blob/master/lsf_drmaa/job.c#L803-831) making sure that SUB_NOTIFY_END is not set!

The if condition basically says if the session's prepand_report_to_output boolean is false, and the SUB_NOTIFY_END option is not set, and the output_path is not null:

if( !((lsfdrmaa_session_t*)session)->prepand_report_to_output
                &&  (req->options & SUB_NOTIFY_END) == 0
                &&  output_path != NULL )

The session variable prepand_report_to_output is set from the configuration file in session.c and it defaults to false. It is set from lsf_drmaa.conf by the (undocumented) prepand_report configuration directive.

We are able to work around our issue by setting:
prepand_report: 1 in lsf_drmaa.conf

I don't know what prepand_report is meant to do (is that a misspelling of "prepend" or is it meant to be "prep_and_report"?) and cannot find any documentation on it, but the default behaviour of lsf-drmaa in which SUB_NOTIFY_END is forced to be set even when email is specifically blocked doesn't seem right.

@adamsla
Copy link
Contributor

adamsla commented May 7, 2018

Were you able to resolve this issue internally?

@adamsla adamsla added the unverified This bug has not been verified by developers label May 7, 2018
@jrandall
Copy link
Author

We continue to employ the workaround, which is to set prepand_report: 1 in lsf_drmaa.conf

@jrandall
Copy link
Author

Possible fixes for this issue:

@mp15
Copy link

mp15 commented Jun 2, 2022

Still running into this issue 7 years later (later version of cluster with same no emails policy). Would you except a pull request to implement one of Josh's fixes?

@TheWitness
Copy link

I would say yes. That's why, before I left IBM, we placed these API's on GitHub. Somebody has to create the pull request though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unverified This bug has not been verified by developers
Projects
None yet
Development

No branches or pull requests

4 participants