Incorrect error strings reported for end-user application failures

[sfayer]

Hi,

We've had a long running annoyance where the ApplicationStatus reported back for failed user jobs has the wrong error message. For example, if a user job script runs an invalid command, bash will exit with error code 127; the error displayed in the ApplicationStatus field will be "Key has expired ( 127 : submit Exited With Status 127)".
A similar thing happens if the user payload returns error code 1 for any reason "Operation not permitted ( 1 : submit Exited With Status 1)".
This causes user confusion "what key has expired? What am I not permitted to do?" but in both of these cases these are the wrong error messages; the bash exit code has been processed by strerror as if it's an errno value, but it isn't.

I think this is happening here, the application exit code is included in a RuntimeException:

DIRAC/src/DIRAC/Workflow/Modules/Script.py

Line 134 in b627e05

raise RuntimeError(f"'{os.path.basename(self.executable).split('_')[0]}' Exited With Status {status}", status)

and then this gets set as the error number in D_ERROR which runs strerror on it:

DIRAC/src/DIRAC/Workflow/Modules/ModuleBase.py

Line 142 in b627e05

return S_ERROR(rte.args[1], rte.args[0]) # rte[1] should be an error code

Would it be possible to somehow prevent these exit codes getting processed into errno style error messages?

Regards,
Simon

[fstagni]

@arrabito do you have the same issue?

[chrisburr]

This was added for #3394 we probably don't need this option any more as we don't use in LHCb anymore.

[arrabito]

Yes we have the same issue.