Running local programs is one of the main reasons for scheduling joblets on resources. Although you are not allowed to run local programs on the server side job portion of JDL, there are two ways to run local programs in a joblet:
Use the built-in system() function.
This function is used for simple executions requiring no output or process handling. It simply runs the supplied string as a shell command on the resource and writes stdout and stderr to the job log.
Use the Exec JDL class.
The Exec class provides flexibility in how to invoke executables, to process the output, and to manage the process once running. There is provision for controlling stdin, stdout, and stderr values. stdout and stderr can be redirected to a file, to the job log, or to a stream object.
Exec provides control of how the local program is run. You can choose to run as the agent user or the job user. The default is to run as the job user, but fallback to agent user if the job user does not exist on the resource.
For more information, see Exec.
The Exec function provides controls for specifying how to handle stdout out stderr. By default, Exec discards the output.
The following example runs a program that directs stdout and stderr to the job log:
e = Exec()
e.setShellCommand(cmd)
e.writeStdoutToLog()
e.writeStderrToLog()
e.execute()
The following example runs a program that directs stdout and stderr to files and opens the stdout file if there is no error in execution:
e = Exec()
e.setCommand("ps -aef")
e.setStdoutFile("/tmp/ps.out")
e.setStderrFile("/tmp/ps.err")
result = e.execute()
if result == 0:
output = open("/tmp/ps.out").read()
print output
You can choose to run local programs and have file operations done as the agent user or the job user. The default is to run as the job user, but fallback to agent user if the job user does not exist on the resource. These controls are specified on the job. The job.joblet.runtype fact specifies how file and executable operations run in the joblet in behalf of the job user, or not.
The choices for job.joblet.runtype are defined in the following table:
Table 7-1 Job Run Type Values
There is also a fact on the resource grid object that can override the job.joblet.runtype fact. The fact resource.agent.config.exec.asagentuseronly on the resource grid object can overwrite the job.joblet.runtype fact.
This ability to run as the job user is supported by the enhanced exec feature of the Orchestrator agent. A resource might not support the Orchestrator enhanced execution of running as job users. If the capability is not supported, the fact resource.agent.config.exec.enhancedused is False. This fact is provided so you can create a resource or allocation constraint to exclude such a resource if your grid mixes resource with/without the enhanced exec support and your job requires enhanced exec capabilities.
An exception in JDL will fail the job. By default, an exception in the joblet will fail the joblet. The job.joblet.* facts provide controls on how many times a failure will fail the joblet. For more information, see Section 7.13, Improving Job and Joblet Robustness.
try :
< JDL >
except:
exc_type, exc_value, exc_traceback = sys.exc_info()
print "Exception:", exc_type, exc_value
JDL also provides the fail() function on the Job and Joblet class for failing a job and joblet. The fail() function takes an optional reason message.
You would use fail() when you detect an error condition and wish to end the job or joblet immediately. Usage of the joblet fail() fails the currently running instance of the joblet. The actual failed state of the joblet occurs when the maximum number of retries has been reached.