FTS Administration guide and administrative procedures.

This document applies to FTS version 2.2

Setting up managers

Manager classes

There are three classes of managers:

• Service managers
• Channel managers
• VO managers

A service manager can perform any operation on the service. This role should be used to setup the other manager privileges.

The /opt/glite/etc/glite-data-transfer-admin-mapfile file on web service machines contains the DNs of the service managers.

By default the file contains only one entry, the host certificate of the machine, so that full service admininstration priviliges are only available from the root account on the web-service server machine. It is recommended to leave this as is.

A channel manager can:

• change channel parameters
• view all jobs on the channel (irrespective of VO)
• cancel any job on the channel (irrespective of VO)

for the channel for which he is administrator.

The participating site admins should be added here (per channel).

A VO manager can:

• change VO job priorities
• view all VO jobs (irrespective of channel)
• cancel all VO jobs (irrespective of channel)

The VO production managers should be added here.

Performing management operations

To perform any management operation, you must have a valid grid or VOMS proxy:

voms-proxy-init

or

grid-proxy-init

and you must be authorizedi, either as a service administrator or as a channel or vo administrator, to perform the operation.

Listing roles

Running the command glite-transfer-getroles will show what roles you have upon the service together with the principal that caused you to have the privilege (either your certificate DN or a VOMS role in your certificate).

For example, running the command as root on a web service machine:

(root@fts101) ~ # glite-transfer-getroles
Your current clientDN is: /DC=ch/DC=cern/OU=computers/CN=fts101.cern.ch

You are authorised as Service Admin because your cert contains the following principal: /DC=ch/DC=cern/OU=computers/CN=fts101.cern.ch

You are not authorised to submit to this service.

You are VO manager for 0 VOs.

You are channel manager for 0 channels.

With a personal certificate:

(zbrox@fts101) ~ $ glite-transfer-getroles
You current clientDN is: /DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox

You are authorised to submit to this service because your cert contains the following principal: /DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox

You are VO manager for 1 VOs.
You are VO manager for VO <dteam> because your cert contains the following principal: /DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox

You are channel manager for 1 channels.
You are channel manager for channel <CERN-CERN> because your cert contains the following principal: /DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox

Channel managers

To list channel managers use =glite-transfer-channel-listmanagers channel =:

(root@fts101) ~ # glite-transfer-channel-listmanagers CERN-CERN
/DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox
/DC=ch/DC=cern/OU=grid/CN=Prostetnic Vogon Jeltz

To add a channel manager use =glite-transfer-channel-addmanager channel principal =:

(root@fts101) ~ # glite-transfer-channel-addmanager CERN-CERN "/DC=ch/DC=cern/OU=grid/CN=Arthur Dent"

To remove a channel manager use =glite-transfer-channel-removemanager channel principal =:

(root@fts101) ~ # glite-transfer-channel-removemanager CERN-CERN "/DC=ch/DC=cern/OU=grid/CN=Arthur Dent"

VO managers

To list vo managers use =glite-transfer-listvomanagers vo =:

(root@fts101) ~ # glite-transfer-listvomanagers dteam
/DC=ch/DC=cern/OU=grid/CN=Zaphod Beeblebrox
/DC=ch/DC=cern/OU=grid/CN=Ford Prefect

To add a vo manager use =glite-transfer-addvomanager vo principal =:

(root@fts101) ~ # glite-transfer-addvomanager dteam "/DC=ch/DC=cern/OU=grid/CN=Arthur Dent"

To remove a vo manager use =glite-transfer-removevomanager vo principal =:

(root@fts101) ~ # glite-transfer-removemanager dteam "/DC=ch/DC=cern/OU=grid/CN=Arthur Dent"

Server administration

This section describes the basic usage and administration of FTS and the format, location and contents of the logfiles. It refers to both the FTS web-service and the FTA agent daemons.

SysV configuration

FTS web-service

The FTS web-service runs inside the Tomcat 5 J2EE container. This is controlled by the /etc/init.d/tomcat5 SysV script. It starts a single Java process daemon with user tomcat4:tomcar4. (sic: Tomcat 5 running under user tomcat4.) It is ckconfig'd to start on runlevels 2,3,4,5.

FTA agent daemons

The FTA daemons are C++ daemons. They are all controlled by the /etc/init.d/transfer-agents SysV script. By default, this script will apply the given action to all the configured FTA daemons on the server.

Each daemon is prefix with the name glite-transfer- and runs with user edguser:edguser.

All daemons are ckconfig'd to start on runlevels 2,3,4,5.

FTS Web-service Portal

Starting the FTS web-service

To start the service:

service tomcat5 start

this will start the Java Tomcat 5 daemon under userid tomcat4:tomcat4. The web-service itself takes a few seconds to start up within the servlet container. Check for success of failure in /var/log/tomcat4/catalina.out.

Stopping the Tomcat web-service

To stop the service:

service tomcat5 stop

Reconfiguring the Tomcat web-service

If a configuration change must be made to the webservice, edit the site-info.def file, rerun the YAIM configuration script to rebuild the Tomcat config files, and then restart the daemon.

1. /opt/glite/yaim/scripts/configure_node site-info.def FTS2
2. service tomcat5 restart

Advanced: Tomcat DB connection pool tuning

The Tomcat container maintains a connection pool to the database. The defaults are tuned for reasonable-load production.

By default, Tomcat will maintain a single open connection. It will open more, as necessary, up to a maximum of 50 concurrent DB connections. It will allow no more of than 30 of these to be idle at any one time (closing connections if there are too many idle). The DB transaction time is short compared to the overall web-service operation, so 50 DB connections can serve many concurrent web-service clients without any queuing on the server.

The parameters can be changed in the file:

/etc/tomcat5/Catalina/localhost/glite-data-transfer-fts.xml

• maxActive sets the maximum number of open connections (default is 50). This maximum should be less than the maximum number of sessions allowed on the database account.
• maxIdle sets the maximum number of connections to keep open (default is 30)

Any changes require a server restart:

service tomcat5 restart

Note that these tunings will be lost if you rerun the YAIM configuration script (these advanced tunings will be moved into YAIM in a future version).

FTA Agents

Starting the FTA agent daemons

To start all the agents:

service transfer-agents start

this will start all the configured agent daemons, one-by-one.

To start just an individual instance:

service transfer-agents start --instance glite-transfer-channel-agent-urlcopy-CERN-CERN

where glite-transfer-channel-agent-urlcopy-CERN-CERN is the name of the channel agent to start.

Stopping the agent daemon

To stop all the agents:

service transfer-agents stop

this will stop all the configured agent instances one-by-one.

To stop just an individual instance:

service transfer-agents stop --instance glite-transfer-channel-agent-urlcopy-CERN-CERN

where glite-transfer-channel-agent-urlcopy-CERN-CERN is the name of the channel agent to stop.

Reconfiguring the FTA agents

If a configuration change must be made to the service, edit the site-info.def. file, rerun the YAIM configuration script to rebuild the config files, and restart the agent or agent(s).

/opt/glite/yaim/scripts/configure_node site-info.def FTA2

The configuration script will report which agent instances have changed configuration. You should restart each of them individually:

service transfer-agents restart --instance glite-transfer-channel-agent-urlcopy-CERN-CERN

or, if the majority have been changed, you can restart all of them simply with:

service transfer-agents restart

Logfiles

The FTS service consists of two independent daemon types:

• the FTS web-service portal running inside the Tomcat application server
• the FTA transfer agents (channel agents and VO agents), which run as a set of normal unix daemons.

All the logfiles are independent. Additionally, when the channel agent daemon needs to perform a transfer, it forks, and then starts logging the results of that transfer into a distinct logfile.

FTS webservice logfiles

The webservice logfiles can be found in /var/log/tomcat4/.

1. catalina.out. This is the least useful logfile and logs only critical container events. Generally no application logging goes here.
2. glite-security-trustmanager.log. This contains the authentication result of every call to the web-service. It is best avoided since the information is duplicated in other logs.
3. org.glite.data. This is the primary logfile for the FTS webservice and will be very verbose since it runs in DEBUG mode. This is the first place to look if the webservice or the client commandline tools start to misbehave. DB errors and service startup errors are usually flagged as ERROR or FATAL catagory and are always accompanied by a Java stack trace in the log to indicate why and where they occurred. In particular, if a client command line produces the message "Internal server error" then this is the logfile to look into.
4. org.glite.data.transfer.fts-calls. This logs, one line per call, normal user-level calls to the webservice (those made to the File Transfer port-type). The method and its paramters are logged, together with the hostname and DN of the calling client.
5. org.glite.data.transfer.channeladmin-calls. This logs, one line per call, channel management calls to the webservice (those made to the Channel Management port-type). The method and its paramters are logged, together with the hostname and DN of the calling client.

All the FTS logfiles are rotated daily provided the service is running. The rotation is done by the log4j tool writing the logfile - there is no explicit logrotate script. The rotated logs are subsequently gzipped by a root cron job installed in /etc/cron.d/, since the log4j software does not support zipping of rotated logs.

FTA agent daemon logfiles

The FTA agent daemons log into /var/log/glite/ with a logname:

glite-transfer-channel-agent-urlcopy-INSTANCENAME.log glite-transfer-channel-agent-srmcopy-INSTANCENAME.log glite-transfer-vo-agent-INSTANCENAME.log

depending on the agent type, where INSTANCENAME is what you specified in the FTS server configuration file. There is one logfile per agent instance.

Using the default configuration, the daemons logs at INFO level which means individual actions (starting and stopping a transfer) as well as errors and warning will be displayed. Normal startup configuration parameters will also be logged. If the agent starts to develop problems, your FTS support may ask you to up the logging to DEBUG. To do this, edit the site-info.def file adding the line below for the instance in question:

   FTA_CERN_BNL_LOG_PRIORITY=DEBUG

where CERN-BNL is the instance name in this example. You should then reconfigure the agent as described above.

All the agent logs are rotated by the root logrotate daily cron job from the script /etc/logrotate.d/glite-data-transfer-agents. All agents daemons are restrated by the postrotate script.

FTA transfer logfiles

By far the largest amount of logging will be produced from the individual transfer logfiles, since in the recommended configuration, this should be run at DEBUG level. These are all put under the directory /var/tmp/glite-url-copy-edguser/.

Active logfiles (those still that are being written to by an active transfer process) are directly in:

/var/tmp/glite-url-copy-edguser/.

Logfiles of completed jobs get put in:

/var/tmp/glite-url-copy-edguser/CHANNELNAMEcompleted/

while logfiles of failed jobs get put in:

/var/tmp/glite-url-copy-edguser/CHANNELNAMEfailed/

There is one pair of directories (failed and completed) for every CHANNELNAME that has run a job on the server.

The is one logfile for every transfer attempted. Once a file transfer status has been determined (either failed or completed) it's logfile is moved to the relevant directory and no longer written to). The logfile names consist of the channel name plus a datestamp plus a mktemp hash; there too many to give sensible names. For example, a failed transfer log on the CERN-RAL channel could look like:

/var/tmp/glite-url-copy-edguser/CERN-RALfailed/CERN-RAL__2006-05-03-1023_JHqepc

The contents of the logfile for a single 3rd party copy log all the steps that the transfer went through:

• SRM get on the source file
• SRM put on the destination file
• gridFTP transfer of file
• SRM set status done on source file
• SRM set status done on the destination file

If any steps need to be retried, you may see multiple versions of the same step. If possible, errors returned from gridFTP and SRM are logged. There are timestamps on all of the entries.

NOTE! The timestamps are in UTC (GMT), NOT the current timezone!

The final entry should always be the status of the transfer together with any error that may have been returned if the transfer failed. This final status and the error is put in the database. Note that if any step after the SRM get or put fails, the process will always attempt to do and SRM setStatus(Done) on the source and destination, to cleanup the state on the SRMs, so you will see this happenning in the logfile. It will also attempt an advisoryDelete on the destination file to clean it up.

The FTS transfer logfiles are not currently cleaned up by default, so the contents of these directories will grow.

FTA transfer logfiles: lost transfers

You may notice a new directory in FTS 2.0 per-channel:

/var/tmp/glite-url-copy-edguser/CHANNELNAMElost/

This is where it puts any transfers that did not complete gracefully. There is a known issue in the Globus VDT 1.2 client we use where upon certain non-protocol compliant errors from one of the gridFTP servers, the Globus code helpfully executes abort(3) inside the library. The SIGABORT isn't reliably caught, so usually the process ends [dis]-gracefully.

In these cases, the failed logfiles are put in the 'lost' directories. You should check for them periodically.

The abort issue should be solved in the VDT 1.6 client that we are slowly migrating towards - this will mean that these bad gridFTP transfers are cleanly failed by the FTS.

The solution to stopping the bad transfers in the first place is usually to restart the (dcache) gridFTP doors on the involved SRM.

Cleaning up FTS transfer logfiles

For large numbers of transfers at high transfer rates, the directory /var/tmp/glite-url-copy-edguser/CHANNELNAMEcompleted/ will end up containing a very large number of small logfiles. There is a script tool /opt/glite/bin/glite-url-copy-cleanlog to clean up these directories and archive the results in a tarfile.

/opt/glite/bin/glite-url-copy-cleanlog -h

shows the help. For example, to cleanup completed logfiles created by the agent user edguser on channel CERN-RAL, cleaning only logfiles older than half a day ago, and archiving the results to /var/glite/transfer-logfile-backup/, run as root:

/opt/glite/bin/glite-url-copy-cleanlog edguser CERN-RAL /root/glite/transfer-logfile-backup 0 0.5

The tool is intended to be run regularly from cron. It is suggested to archive the completed logfile daily for all channels on the system. Failed logfiles can be archived as necessary - and possibly you may wish to inspect them first.

FTS service admimistration and channel management

A more detailed look at channel administration, along with common administrative tasks is described in FtsChannelAdmin20.

Details of the processes running

Doing a ps aux as root will show the running processes.

If the webserver is configured and running on the node you should see:

• a Java process owned by tomcat4:tomcat4. This is the main Tomcat process that runs the FTS webservice application. Running ps auxm will show a number of pooled service threads.

If any agents are configured and running on the node you should see:

• For every configured instance, an agent process called glite-transfer-channel-agent-urlcopy-CHANNELNAME or glite-transfer-channel-agent-srmcopy-CHANNELNAME (for channel agents) or glite-transfer-vo-agent-VONAME owned by edguser:edguser. These are the main agent processes. Running ps auxm should show two threads per instance.

When a channel agent wants to start a new transfer job, it creates a memory mapped file describing the job. It then double forks and calls execlp on glite-url-copy-exec passing the memory mapped file as an argument (the result of which will be called the transfer process). Note this is different from FTS 1.5 (which just double forked away from the parent).

The majority of the transfer process' memory usage exists in shared memory since it consists of Oracle shared libraries; this should be remembered when looking at memory usage with tools such as top. Running ps auxm should show three threads once the transfer process has established itself. After forking, the process is name like:

glite-url-copy-exec CERN-SARA__2007-07-19-1026_oaqzmc

which matches the name of the active logfile in /var/tmp/glite-url-copy-edguser/. In that directory, there is also the memory-mapped file, named like /var/tmp/glite-url-copy-username/CERN-GRIDKA__2006-05-03-1059_9o9ie2.mem. This is used updated by the transfer process and read by the original transfer agent daemon to check the current status of the job.

For debugging purposes, the current status of a running transfer process may be retrieved by running the command line passing the relevant memory mapped file (as the daemon user):

glite-url-copy-print-status GRIDKA-CERN__2007-07-19-1018_v87dX0.mem

or simply cat the active logfile /var/tmp/glite-url-copy-edguser/GRIDKA-CERN__2007-07-19-1018_v87dX0.log

Advanced: debugging the agent daemon or transfer proccesses

The transfer daemon does a chdir to /tmp/ upon forking. Provided the core file size has not be limited by the daemon user or by the system-wide limit configuration (usually set in /etc/security/limits.conf) then any core files from SEGV failures or similar should be in /tmp/.

To debug the process with gdb or similar (either process-attached or offline core file), the originating executable is:

/opt/glite/libexec/glite-url-copy-exec

the debugger should follow through the shared libraries to the current execution point. The libraries are built with debugging symbols.

Advanced: debugging the web-service Java process

To do live debugging on the Java Tomcat web-service process, edit the file:

/etc/init.d/tomcat5

and change the daemon and su call in the start method from:

daemon --user $TOMCAT_USER $TOMCAT_SCRIPT start

to:

daemon --user $TOMCAT_USER $TOMCAT_SCRIPT jpda start

and restart tomcat:

service tomcat5 restart

This will open a JPDA debugging port on tcp/5000 that you can connect to with a Java debugger. FTS/FTA FAQ

Channel administration

Creating new channels

The FtsServerInstall20 guide details how to create channels in the database. In short, you need to:

1. Add a new channel in the DB using glite-transfer-channel-add.
2. Add a new agent daemon configuration to one of your agent nodes to service this new channel.

Managing channels

Initially, try a list to see what channels are already defined on the system (if it is a new install on a blank database, there should be none):

glite-transfer-channel-list

To see a basic view of the channel:

glite-transfer-channel-list CHANNELNAME

To see a fuller view of the channel:

glite-transfer-channel-list -x CHANNELNAME

note that man pages are available for all commands.

Problems you may see

If you see:

list: listChannels: SOAP fault: SOAP-ENV:Client - CGSI-gSOAP: Could not open connection ! (TCP connect failed in tcp_connect())

then either the service is down, or your services.xml file is pointing to the wrong endpoint. You can see what endpoint the client is attempting to connect to by using the version flag:

glite-transfer-channel-list -v

If you see:

list: Service discovery: No services of type org.glite.ChannelManagement were found

then either the services.xml file is missing or not readable by the client.

If you see:

list: listChannels: SOAP fault: "http://xml.apache.org/axis/":Server.NoService - The AXIS engine could not find a target service to invoke!  targetService is ChannelManagement

then either the endpoint specified in the services.xml file is incorrect, or the service is misconfigured.

To check whether the endpoint specified in the services.xml file is correct, connect to it directly with a web browser. e.g. connect to https://yourhostname:8443/glite-data-transfer-fts/services/FileTransfer (you will need your grid certificate loaded in your browser). If the service is listening, you should see a web page with a message like:

Hi there, this is an AXIS service!

If you see:

list: listChannels: You are not authorised for channel management upon this service

then you are not in the manager mapfile. Look in the FTS server logs (org.glite.data) to see how the authorisation decision was made.

Changing the state of channels

Although any parameters may be changed subsequently on a channel, only three operations are common: setting it active, setting it inactive and setting the number of concurrent transfers. Note (new in FTS 2.0) it is recommend to add a comment using the -m option.

To set a channel mychannel to state Inactive:

glite-transfer-channel-set -S Inactive CHANNELNAME -m "Because I can"

This will stop putting any further work on the network. Any individual file transfers that have already been started will complete, so it can take a minute or two for all activity to stop.

To set the channel to state Active:

glite-transfer-channel-set -S Active CHANNELNAME -m "Set back to normal operations"

This will start putting work on the network if there are any jobs assigned to that channel in the Pending state.

To change the number of concurrent transfers being put on the network for a given channel:

glite-transfer-channel-set -f 10 CHANNELNAME -m "Increase to 10 to see what happens to the rate"

This will make the agent try to maintain 10 concurrent transfers on the channel when it is Active.

Auditing operations

The channel-set commands are audited by the service. You can view previous operations using the comand:

glite-transfer-channel-audit CHANNELNAME

Dropping channels

To drop a channel:

glite-transfer-channel-drop CHANNELNAME

It is a current restriction that a channel cannot be dropped if any jobs have been assigned to it (because we do not cascade constraints on the database delete). We will provide a script to do this soon. Make sure that you are happy with a channel definition before submitting work that will be assigned to it.

Setting a per-VO share on a channel

This can be done using the command:

glite-transfer-channel-setvoshare VONAME CHANNELNAME SHARE

where the shares are all calculated relative to one another (the absolute value is not important). Note also, that in the default mode, the shares are 'elastic' in that if one VO has no jobs, the others will absorb its share until it returns.

To stop a VO transferring for a while, set the share to 0. New jobs will be queued onto the channel.

To remove a VO from a channel, set the share to "-1" (using getopts -- feature). New jobs will be rejected from the channel.

Setting a per-VO cap on a channel

The elastic nature of the share can cause problems when a SRM pool is not sized to take the full number of transfers configured on a channel. This was noted particularly for the dteam background transfers when, in some quiet times, there were no jobs from any of the experiments - this caused dteam to absorb the entire share of the channel which overloaded the source and destination dteam disk pools with too man requests.

It is therefore possible to limit the maximum number of jobs for a given VO on a channel:

glite-transfer-channel-setvolimit VONAME CHANNELNAME LIMIT

where LIMIT is the number of concurrent files.

To remove a limit, set it to "-1" (using getopts -- feature).

Channel managers

To view current channel managers:

glite-transfer-channel-listmanagers

To set and remove someone as a channel manager, using their quoted certificate subject name:

glite-transfer-channel-addmanager CHANNELNAME "/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=mccance/CN=453200/CN=Gavin Mccance"

glite-transfer-channel-removemanager CHANNELNAME "/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=mccance/CN=453200/CN=Gavin Mccance"

Manual interventions on channels

When a file fails on a single transfer attempt, the system will attempt to retry it after some delay. The number of retry attempts and the delay are configurable on the service (defaults are 3 retries, waiting minimum 10 minutes between each retry attempt).

If a file fails, it will be placed in state Waiting. After the retry period has elapsed it will be placed back in the Ready state, and will subsequently be picked up again by the transfer agent.

Details about "Hold" state (not configured by default)

If a file has been retried more than the max number of times, it is placed in the Hold state. This state indicates that some manual intervention should be made to rescue (or cancel) the file. The channel admin should periodically check for jobs with files in Hold state:

glite-transfer-list -c CHANNELNAME Hold

If there are any, there are two options for you. You may fix the whatever you believe the problem may be (e.g. reboot the SRM cluster) and try for one more retry.

glite-transfer-channel-signal -c CHANNELNAME Pending

All jobs on the channel in Hold state will be dropped back onto the Pending queue. The other option is to set all the jobs on the channel in Hold state to Canceling if you believe that there is nothing you can do to rescue the jobs (for example, if the filenames are invalid).

glite-transfer-channel-signal -c CHANNELNAME Cancel

You also have the option of applying the signal command to a single job, rather than all jobs on the entire channel.

glite-transfer-channel-signal -j 17cc7055-d3ac-11d9-a905-f173b72e4547 Pending

Running a test job

Identify a source SRM file name and a suitable destination SRM file name. The file names must be in the full SURL format:

srm://castorgridsc.cern.ch:8443/srm/managerv1?SFN=/castor/cern.ch/grid/dteam/storage/transfer-test/1gig/file-001.dat

Assuming you are using delegation (as below), you do not need to load a proxy into MyProxy.

voms-proxy-init

glite-transfer-submit \
   srm://castorgridsc.cern.ch:8443/srm/managerv1?SFN=/castor/cern.ch/grid/dteam/storage/transfer-test/1gig/file-000.dat \
   srm://srm1.tier1.sara.nl:8443/srm/managerv1?SFN=/data/dteam/testdestfile-glite-1.1.1-000.dat

choose your SURLs appropriately. This will return a UUID identifier, e.g.

17cc7055-d3ac-11d9-a905-f173b72e4547

To check the status of the job, run:

glite-transfer-status --verbose 17cc7055-d3ac-11d9-a905-f173b72e4547

which should print the state and some other information. You should see the job progressing through:

• Submitted (if you're fast). The job is still to be assigned to channel.
• Pending and Ready. The job has been assigned to a channel, and is awaiting a transfer slot.
• Active. The job is being transferred or the file is awaiting retry.
• Hold. The single file in the job failed 3 times and needs to be rescued by manual intervention.
• Done. The file has completed successfully.
• Finished. The job and its file has completed successfully.
• Failed. The job and its (all of its) file(s) failed.
• Finished. The job and (some of its) file(s) failed.

If the job has entered state Finished, then the test went fine.

VO Administration

Actions

Seeing all jobs in the VO

A normal unpriviliged user can only see his or her own jobs. i.e. the glite-transfer-list result is restricted.

A VO manager can see all jobs belonging to the VO.

glite-transfer-list

Canceling all jobs in the VO

Similar comments apply to canceling a job. A normal unpriviliged user can only cancel his or her own jobs. A VO manager can cancel any job belonging to the VO.

glite-transfer-cancel jobid [jobid...]

Reprioritising jobs

When a job is submitted, it is set with job priority 3. The range is 1 (lowest) to 5 (highest).

A VO manager may change the priority of jobs within the VO.

glite-transfer-setpriority jobid 5

This affects only the priority within the VO. It does not increase the share relative to other VOs. If you want to increase your share on a given channel, please contact the appropriate channel manager (there should be a contact email in the channel description returned by glite-transfer-channel-list).

Procedures

---

Last edit: AkosFrohner on 2009-05-08 - 01:44

Maintainer: PaoloTedesco

---