Quick User Guide for Submitting Jobs

From EGEE-see WIki
Jump to: navigation, search

This guide is a part of SEE-GRID Gridification Guide. It is aimed to be a quick reminder on job submittion. This is a quick overview of tools needed for submitting a grid job. For more detailed guide and troubleshooting refer to page SG Running Jobs WMProxy CLI


List of basic commands for impatient

# create voms proxy: 
voms-proxy-init -voms <VO_NAME>
# create myproxy on proxy server:
myproxy-init -d -n [-s <myproxy_server>]
# delegate proxy to wms
glite-wms-job-delegate-proxy -d <delegID> 
# submit job described in jdl file
glite-wms-job-submit -d <delegID> <jdl_file>
# monitor status of job
glite-wms-job-status <jobID>
# retrieve job output
glite-wms-job-output <jobID>
#cancel job
glite-wms-job-cancel <jobID>
# view proxy info
myproxy-info -d
# destroy proxies
myproxy-destroy -d

This is a quick overview of tools needed for submitting a grid job. For more detailed guide and troubleshooting refer to page SG Running Jobs WMProxy CLI

Certification and Authorization

In order to use Grid resources, first you need to have a valid certificate and become a member of one or more virtual organizations (VO). If you are already a member of VO and you posses valid certificate, proceed to the next section.

For obtaining certificate contact your local Certification Authority (CA). List of SEE-GRID CAs can be found on http://www.grid.auth.gr/pki/seegrid-ca/ra/, and for instructions on requesting and using the certificates refer to page http://www.grid.auth.gr/pki/seegrid-ca/documents/.

In order to register to SEE-GRID VO, visit page https://voms.irb.hr:8443/voms/seegrid/.

For becoming a member of Meteo VO (meteo.see-grid-sci.eu), register at https://voms.grid.auth.gr:8443/voms/meteo.see-grid-sci.eu.

Future Environment VO (env.see-grid-sci.eu) should register at https://voms.ipp.acad.bg:8443/voms/env.see-grid-sci.eu, while members of Seismological community can manage their seismo.see-grid-sci.eu VO membership at https://voms.ulakbim.gov.tr:8443/voms/seismo.see-grid-sci.eu

If you don't know which VO is right for you, you can see full list of registered VOs here

You're also welcome to visit our Users Wiki Page

Importing user certificate on UI

Here, it is assumed that you already have access to configured UI. If you don't have it, ask your system administrator to create an account for you. If this is not possible, you can install and configure UI on your local machine, by following the instructions given here.

After obtaining your certificate, place it in your $HOME/.globus directory on the User Interface that you are using together with corresponding user key (if this directory doesn't exist, create it). Name of the user certificate file should be usercert.pem and key file should be named userkey.pem. If, for any reasons, you don't want to use default path and names, you should set environment variables $X509_USER_CERT and $X509_USER_KEY to point to your certificate and user file. For security reasons it is necessary to set the permissions of userkey.pem to 400, i.e. to be readable only by the owner. In other cases many grid operations would fail.

More informations on environment variables regarding authorization and authentication can be found here.

Generating proxy


Submitting job to grid infrastructure requires that you have a valid proxy. If your user credentials are valid and in place, you can create voms-proxy by issuing command

voms-proxy-init -voms <VO_NAME>

replacing <VO_NAME> with name of your VO (for example seegrid). You can see informations about voms-proxy or destroy it with following commands:



By default voms-proxy is valid for 12 hours. All jobs that are not finished at the time when voms-proxy expire, will be terminated. There are two ways to avoid this:

  • set longer life time of proxy with option -hours <time>. This is not recommended due to security issues.
  • by using proxy renewing method by creating myproxy with command
myproxy-init -d -n

By doing this, you are creating long-term proxy on dedicated server specified in $MYPROXY_SERVER. You can use different server by specifying it with -s option

myproxy-init -d -n -s <myproxy_server>

Option -n is used to avoid use of passphrase to access long-term proxy, so that WMS could perform renewal automatically, and with -d option user DN is associated to the proxy.

Default lifetime of myproxy is one week and proxies created from it lasts 12 hours. This times can be changed by using the -c ant the -t options respectively.

Myproxy can be viewed or destroyed from myproxy server with following commands:

myproxy-info -d -s <myproxy_server>
myproxy-destroy -d -s <myproxy_server>

Note: If your job is not finished before myproxy expires, you just need to recreate myproxy with myproxy-init command, while if you're just using long-term voms-proxy, prolonging it would not be possible.

Note: In order to manipulate your jobs or files you must have valid voms-proxy on your UI. Proxy renewal method with myproxy is used only by grid services (such as WMS), and when voms-proxy on your UI expires, you need to create new one manually in order to have access to grid resources.

Delegate proxy to WMS

Each job submitted to the gLite WMS must be associated to a proxy credential previously delegated by the owner of the job to the WMProxy server. This proxy is then used any time WMProxy needs to interact with other services for job related operations.

There are two ways to delegate one’s credentials to WMProxy:

  • by having the delegation performed automatically each time a job is submitted,
  • by explicitly creating a named delegated credential on theWMProxy server, and subsequently referring to it each time a job is submitted.

The advantage if the former method is simplicity, while that of the latter is better performance (as delegation may require a non-negligible amount of time).

For automatic proxy delegation issue the command

 glite-wms-job-delegate-proxy -a

and use -a option when submitting a job:

 glite-wms-job-submit -a test.jdl

For creating a named delegated credential on theWMProxy server:

glite-wms-job-delegate-proxy -d <delegID>

and use -d option when submitting a job:

glite-wms-job-submit -d <delegID> test.jdl

Job operations

Job submision

As mention above, job is being submittet with glite-wms-job-submit with -d or -a option for delegating proxy. The last argument of this command is Job Description Language (jdl) file, which contains all the informations about job and its requirements. For detailed informations on creating jdl files, please refer to the latest version of Job Description Language Attributes Specification

The simple example of jdl file is given below:

Executable = "hello.sh" ;
StdOutput = "stdout.txt";
StdError = "stderr.txt";
InputSandbox = {"hello.sh"};
OutputSandbox = {"stdout.txt", "stderr.txt"};

In Executable name of executable file is given. It can be a file that is already on a WN (for example /usr/bin/java), or, as in example above, it can be a file from local UI, that you have to put in InputSandbox in order to be transferred to final destination where it will be executed.

StdOutput and StdError are name of the files where you want your standard output and standard error to be printed. You can retrieve those files by placing it into OutputSandbox.

InputSandbox is list of all files that need to be transferred to WN in order to execute the job. That can include executable file and all input files. OutoutSandbox contains the list of all output files that you want to retrieve upon job execution. All output files that are not in this list will be deleted after job is done.

After job is successfully submitted, unique ID of job is printed to your screen. Job ID is of the form https://<wms-server>:<port>/<hash-number> (for example: https://wms.phy.bg.ac.yu:9000/TwGesnhiYkjfOfYuGkK3Nw). It is recommended for you to save this ID. This ID can also be printed directly to file by using -o option with the submit command

glite-wms-job-submit -d <delegID> -i <job_id_file> test.jdl

If this file already exist, a new line with job ID will be appended at the end of file.

Monitoring jobs

Status of jobs can be viewed at any time with

glite-wms-job-status <job_ID>

or if job ID is saved in the file

glite-wms-job-status -i <job_id_file>

or if you want to see status of all your jobs

glite-wms-job-status --all

Job status can be one of the following: Submitted, Waiting, Ready, Scheduled, Running, Done, Cleared, Aborted, Cancelled and Purged.

Logging details on submitted job can be accessed via

glite-wms-job-logging-info -v <verbosity_level> <job_ID>

or if job ID is saved in the file

glite-wms-job-logging-info -v <verbosity_level> -i <job_id_file>

Verbosity level can be from 0 to 3.

Cancel job or retrieve output

If you want to cancel submitted job, you can do it with

glite-wms-job-cancel <job_ID>

or if job ID is saved in the file

glite-wms-job-cancel -i <job_id_file>

After job status is Done, you can retrieve files from Output Sandbox with

glite-wms-job-output <job_ID>

or if job ID is saved in the file

glite-wms-job-output -i <job_id_file>

Files are then saved to your local machine in directory that is specified within your UI configuration. You can override the default path with --dir option

glite-wms-job-output --dir <directory_path> <job_ID>

Advanced job types and operations

Sometimes you might need to do more then just submitting single job and waiting for it to be done in order to get your results. You may want to submit many similar jobs with just altering parameters, or you want to submit several different jobs at once which can be independent or even dependent on other jobs output. You may want to watch your output files while the job is being executed, or use files on remote storage elements for input and output of your jobs. All this, and more is available to you by using WMS at advanced level. Here are some quick user guides on how to do the following

Personal tools