4.5.2.4.
Testing the Platform Scripts
Up one level
This section describes how to test platform scripts after they have been installed and configured, using the pre-supplied test application. The details of command lines, etc, are specific to the test application only.
All platform scripts should be able to run as stand-alone applications from a command line. Before running any of the tests, make sure that:
- the test application is installed and configured properly, e.g. properties files, etc
- you can submit and run jobs successfully via the cluster resource manager (e.g. PBS) if you are using one
- the scratch directory you are using, e.g. /scratch, is accessible by both front-end system and compute nodes.
- Create a temporary workspace directory:
$ mkdir /scratch/testgrid/work/{inputs,outputs} $ cd /scratch/testgrid - Copy an image file to job workspace, e.g.
$ cp some_demo.jpg /scratch/testgrid/inputs/input-0
Running a Job
The default location for scripts can be found under WRAPPERS_DIRECTORY/platform. To test the startJob script, use the following command (N.B. directory locations may vary depending on where the scripts may have been copied to):
$ /opt/gria-platform-scripts/rm_local/startJob -v -d /scratch/testgrid -e /opt/tutorial-apps/swirl/startJob
This will run the test application and store the output results in the outputs subdirectory. The working subdirectory is set to work. The response should look like:
Session directory: 1149159584 Job submitted successfully
Checking the Job Status
From the command line type:
$ /opt/gria-platform-scripts/rm_local/getJobStatus -e /opt/tutorial-apps/swirl/checkJob -d /scratch/testgrid
A typical response of this command will produce something like:
DEBUG Use session directory: /scratch/testgrid DEBUG Use application status script: +----------------------------------------------------+ | | | GRIA Job getStatus wrapper ($Revision: 4190 $) | | | +----------------------------------------------------+ Resource Manager...: Local execution Check job status time....: Thu Jun 1 11:59:44 2006 DEBUG Using session name: testgrid DEBUG Using concat session name: testgrid DEBUG JOB_PID file found! Local job ID.........: 2286 DEBUG Detected platform: Unix DEBUG qString: pagis 2286 1 0 11:59 pts/2 00:00:00 perl /scratch/testgrid/jdf.pl pagis 2289 2286 0 11:59 pts/2 00:00:00 /usr/bin/perl /opt/tutorial-apps/paint/startJob.pl JOB_STATUS RUNNING JOB_SUBMITTED 1149159584000 APP_WRAPPER_STARTED 1149159584000 <------------------------> JOB_STATUS RUNNING JOB_SUBMITTED 1149159584000 APP_WRAPPER_STARTED 1149159584000 <------------------------> Appliction specific status not available Check job status exit code: 0
Note: getStatus is using STDOUT to provide the job status report to Job Service while STDERR is used for debugging information. The two output streams will be mixed on the screen unless you redirect one to a separate file e.g. 2>status.err.
Killing a Job
From the command line, type:
$ /opt/gria-platform-scripts/rm_local/killJob -v -d /scratch/testgrid
The response from this command will be similar to:
Try to kill the job Use session directory: /sratch/testgrid Use application specific kill script: killJob ver: 5.0.0 +--------------------------------------------------+ | | | GRIA Job killJob wrapper ($Revision: 4190 ) | | | +--------------------------------------------------+ Thu Jun 1 12:00:00 2006 session name: testgrid DEBUG JOB_PID file found! DEBUG PID: 2286, 2286, 2286 DEBUG Detected platform: unix DEBUG qString: <> DEBUG Job is not found in Q Job is not running, it cannot be killed because it has already finished Kill job exit code: 0
After a job has completed successfully the workspace directory will have a directory structure similar to:
testgrid/
|-- .app_wrapper_ended
|-- .app_wrapper_exit_code
|-- .app_wrapper_started
|-- .jobPID
|-- .job_submitted
|-- jdf.pl
|-- log
|-- resources.xml
`-- work
|-- image.jpg
|-- inputs
| `-- input-0
`-- outputs
`-- output-0
