FTA change channel type procedure for Release 2.0.

What is it?

When to use it?

Reason

When the channel agent daemon runs, it periodically checks for the status of the running transfers. This status is serialized in the .mem files that can be found under the /var/tmp/glite-url-copy-edguser folder, and these files have a different structure if the transfer is an urlcopy or srmcopy mode transfer. Therefore, it is possible that something like the following happens:

• the urlcopy channel agent is stopped while there are running transfers
• the channel type is set to srmcopy
• the channel agent is restarted
• the agent picks up an urlcopy mem file and tries to read it as an srmcopy mem file
• the transfer status verification fails.

Possible consequences are:

• transfers that were actually successful are considered failed and retried
• database corruption: on some occasions two active transfers for the same file are created in the database, and eventually the channel agent will disable many of its actions, not being able to cache the active transfers data.

Procedure

Drain and stop the channel

glite-transfer-channel-set -S Inactive CERN-CERN

ps aux | grep CERN-CERN__ 

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

Change the channel type

FTA_CERN_CERN="URLCOPY"

FTA_CERN_CERN="SRMCOPY"

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

Restart the channel

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

Troubleshooting

Why

The problem stems from the fast that the lock file is a function of the agent name - so glite-transfer-channel-agent-srmcopy-CERN-CERN and glite-transfer-channel-agent-urlcopy-CERN-CERN have different lock files. Consequently, both agents can be running on the same schema at the same time, and this causes the DB corruption.

I can't stop the old agent

If you do not stop the old agent before reconfiguring YAIM, the init.d script will not let you address the old agent (i.e. the stop command won;t let you stop it). In this case, you should kill the old agent with SIGINT.

The newly configured channel is 'stuck'

If you have already had both the agent running at the same time, there is a risk of schema corruption. The new agent will check for a valid schema a disable itself if it finds a problem. Of course these means the agent is effectively down until you fix the schema. The symptom is that all jobs on the channel will stay in the Ready state. If you look in the log file of the channel agent you will find messages about actions being disabled. In this case contact fts-support@cernNOSPAMPLEASE.ch for the fix.

Maintainer: PaoloTedesco