Last modified: Tue Jan 9 17:00:20 GMT 2007
Nick West
Return to home page

Grid: Running Jobs

Last modified: Fri Oct 3 10:48:02 BST 2008
Nick West
Return to home page

Reference: glite-wms-job-* commands

For an introduction see Submitting jobs

Caution: Before you can use the glite-wms-job-* commands you must set up a Short Term Proxy

Also, make sure that it is properly configured at your UI.

This section briefly describes each of the glite-wms-job-* commands. For a full list of options that each command supports use the info commands e.g. 

  info glite-wms-job-list-match
Note that there is also a set of glite-job-* commands, these are an earlier API using the Network Server. Do not use this API. It lacks some functionality provided by the later one.

Matching computing elements (glite-wms-job-list-match)

Syntax: glite-wms-job-list-match <JDL file>

Options:-
 -a  Automatic delegation
 -d  <dID>  Use a previous explicitly delegated proxy.

  must use either -a or -d

  -o <file> Store the CE list in a file
List the CEs that can accept the job.

Proxy delegation (glite-wms-job-delegate-proxy)

Syntax: glite-wms-job-delegate-proxy -d  <dID>
This delegates a proxy to the WMProxy and assigns it the supplied ID which should be used with the -d option on subsequent glite-wms-job-list-match and glite-wms-job-submit commands.

Job submission (glite-wms-job-submit)

Syntax: glite-wms-job-submit <JDL file>

Options:-
 -a  Automatic delegation
 -d  <dID>  Use a previous explicitly delegated proxy.

  must use either -a or -d

 -o  <file> Append jobId to specified file (creating if necessary)
 -r  <CE>  Send a job directly to a particular CE. 
             Don't check CE for suitability or create a BrokerInfo file.
Submit job to the GRID.

The command returns to the user the job identifier (jobId), which uniquely defines the job and can be used to perform further operations, like interrogating the system about its status, or cancelling it. The format of the jobId is: 

  https://Lbserver_address[:port]/unique_string
This is not a web page!

Job status (glite-wms-job-status)

Syntax:  glite-wms-job-status <jobId1> ... <jobIdn>

Options:-
 -i <file> Input file (filled by glite-wms-job-submit) and ask user which jobId(s) to report on
 -o <file> Direct output to file
 -v <n>    Select verbosity level n (0,1 or 2)
Report on status of job(s) and when the status was reached.

Job Status Values

Status Definition
SUBMITTED The job has been submitted by the user but not yet processed by the Network Server
WAITING The job has been accepted by the Network Server but not yet processed by the Workload Manager
READY The job has been assigned to a Computing Element but not yet transferred to it
SCHEDULED The job is waiting in the Computing Element's queue
RUNNING The job is running
DONE The job has finished
ABORTED The job has been aborted by the WMS (e.g. because it was too long, or the proxy certificated expired, etc.)
CANCELLED The job has been cancelled by the user
CLEARED The Output Sandbox has been transferred to the User Interface

Job logging (glite-wms-job-logging-info)

Syntax: glite-wms-job-logging-info <jobId1> ... <jobIdn>

Options:-
 -v <n>    Select verbosity level n (0,1 or 2)
 -o <file> Direct output to file
Reports on progress of one or more jobs. Typical output:- 
********************************************************************** 
LOGGING INFORMATION: 
 
Printing info for the Job: https://lxshare0310.cern.ch:9000/C_CBUJKqc6Zqd4clQaCUTQ 
 
        - - - 
 Event: RegJob 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:16 2004 
        - - - 
 Event: Transfer 
- destination          =    NetworkServer 
- result               =    START 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:16 2004 
        - - - 
 Event: Transfer 
- destination          =    NetworkServer 
- result               =    OK 
- source               =    UserInterface 
- timestamp            =    Fri Feb 20 10:30:19 2004 
        - - - 
 Event: Accepted 
- source               =    NetworkServer 
- timestamp            =    Fri Feb 20 10:29:17 2004 
        - - - 
 Event: EnQueued 
- result               =    OK 
- source               =    NetworkServer 
- timestamp            =    Fri Feb 20 10:29:18 2004 
[...]

Job perusal (glite-wms-job-perusal)

Job perusal is the ability to view output from a job while it is running. In order to use this feature the JDL attributes PerusalFileEnable and PerusalTimeInterval must be declared when the job is submitted for example:- 
  PerusalFileEnable = true;
  PerusalTimeInterval = 120;
This makes the WN upload, at regular time intervals (PerusalTimeInterval), a copy of the output files specified using the glite-wms-job-perusal --set command to the WMS machine. Both Ganga and GBS support job perusal.

Caution: The way that file perusal has been implemented means that it is an expensive option. It's fine for debugging but do not use for standard production. Having hundreds of jobs regularly sending files back for perusal can bring a Resource Broker to its knees.

One the job has been submitted, the files that are to be perused are specified using the --set option:- 

Syntax: glite-wms-job-perusal --set -f <file_1> ...  -f <file_n>  <jobIdn>

Example:  glite-wms-job-perusal --set -f stdout.log -f stderr.log -f testfile.txt \
          https://rb102.cern.ch:9000/B02xR3EQg9ZHHoRc-1nJkQ
and then output can be retried, one file at a time, using the --get option:- 
Syntax: glite-wms-job-perusal --get -f <file_m>  <jobIdn>

Example:  glite-wms-job-perusal --get -ftestfile.txt \
          https://rb102.cern.ch:9000/B02xR3EQg9ZHHoRc-1nJkQ

Options:-

  -all        Retrieve file in full.  By default only the portion written since last --get will be returned.
  --dir <dir> Return file to specified directory.  Default: /tmp/<jobId  unique string>>.
Job perusal can be disabled using the -unset option. 
Syntax: glite-wms-job-perusal --unset <jobIdn>

Example:  glite-wms-job-perusal --unset
          https://rb102.cern.ch:9000/B02xR3EQg9ZHHoRc-1nJkQ
It is possible to use glite-wms-job-perusal to examine the final state of a file after the jobs has ended. If all you are want to do is perform a post-mortem, you can just enable perusal in the JDL and activate with glite-wms-job-perusal --set but leave file retrieval until after the job has ended.

Job cancellation (glite-wms-job-cancel)

Syntax: glite-wms-job-cancel <jobId1> ... <jobIdn>

Options:-
 -i <file> Input file (filled glite-wms-job-submit) and ask user which jobId(s) to cancel.
Cancel the selected jobs.

Note: If the job has not reached the CE yet (i.e.: its status is WAITING or READY states), the cancellation request may be ignored, and the job may continue running, although a message of successful cancellation is returned to the user. In such cases, just cancel the job again when its status is SCHEDULED or RUNNING.

Job retrieval (glite-wms-job-output)

Syntax: glite-wms-job-output <jobId1> ... <jobIdn>

Options:-
 -i <file>         Input file (filled glite-wms-job-submit) and ask user for which jobId(s) to return output.
 --dir <directory> Return output to that directory by default, the output is stored under /tmp
Return sandbox output from completed jobs (status DONE) to the UI.

Job output is removed from RB eventually if not retrieved. You should aim to collect all output within a week of job completion.

This section has been plundered from @ gLite 3 User Guide / Section 6.3 The Command Line Interface

Return to home page