4.4.3. Check Job

Unlike the wrapper for starting an application, the application wrapper for reading status from the working directory is optional. If no such wrapper is provided, the platform script will create a simple status report by checking for files like .app-start and .app-end that indicate if and when the job started or finished, consulting the execution platform manager (e.g. batch queue system), and appending .stderr (if any) to the result.

If you want the job status report to include application-specific information such as convergence plots, iteration counters, etc., you should create a wrapper script that will be invoked by the client calling the checkJob method.

An application status wrapper is usually a lot simpler to create than the main wrapper because it does not take any user-supplied (and hence potentially malicious) arguments, and does not set up (or run) potentially untrustworthy code. All the status wrapper has to do is to examine the job's working directory, read any files it needs in order to extract the desired status information (in the limit, one could simply copy an application-level log file), and write it to the standard output.

Note: the format of the status information is open and application dependent, however, status information should not include binary data.

An Example Status Wrapper Script

This example is based on the ImageMagick application, which was installed as part of the GRIA installation and follows on from the start job example. In the same directory as startJob, create a script called checkJob:

#!/bin/sh
tail log

This is run each time the client checks the status of the job. This example simply returns the last few lines of the log file, and is executed as follows:

1. Make the script executable:

   $ chmod a+x checkJob

2. Test it with these commands:

   $ ./checkJob > statusfile
   $ cat statusfile
   

   You should find that the contents of log are now in statusfile.

Next: Kill Job Previous: Start Job