FtsChangeChannelType20 < LCG

LCG Web>FtsWlcg>FtsRelease20>FtsProcedures20>FtsChangeChannelType20 (2008-01-15, unknown) (raw view)

<!--
   * Set ALLOWTOPICCHANGE = Main.DepITGMDMGroup
-->
%INCLUDE{"LCG.FtsMenu"}%
<noautolink>
---+ FTA change channel type procedure for Release 2.0.

---++ What is it?
This is the procedure to change the type of an existing channel from URLCOPY to SRMCOPY or viceversa.

---++ When to use it?
When you have an existing channel, with an agent running for it, configured as URLCOPY or SRMCOPY and want to change the transfer type. 

---++ Reason
Changing the channel type of a channel is not like changing any other parameter and requires particular care. 

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
In the example we will use a channel named "CERN-CERN" and change its type from urlcopy to srmcopy.
---+++ Drain and stop the channel
Set the channel state to *Inactive* so that no new transfers will be started:
<verbatim>
glite-transfer-channel-set -S Inactive CERN-CERN
</verbatim>
Wait until there are no running transfers, i.e. grep the process table for processes of the form =CHANNEL-NAME__*=:
<verbatim>
ps aux | grep CERN-CERN__ 
</verbatim>
Stop the channel:
<verbatim>
service transfer-agents --instance glite-transfer-channel-agent-urlcopy-CERN-CERN stop
</verbatim>
---+++ Change the channel type
Edit the =site-info.def= file. Modify
<verbatim>
FTA_CERN_CERN="URLCOPY"
</verbatim>
to
<verbatim>
FTA_CERN_CERN="SRMCOPY"
</verbatim>
Rerun the YAIM configuration script to rebuild the config files:
<verbatim>
/opt/glite/yaim/scripts/configure_node site-info.def FTA2
</verbatim>
---+++ Restart the channel
<verbatim>
service transfer-agents --instance glite-transfer-channel-agent-srmcopy-CERN-CERN start
</verbatim>
Note that the channel agent instance name has changed from =glite-transfer-channel-agent-<b>urlcopy</b>-CERN-CERN= to =glite-transfer-channel-agent-<b>srmcopy</b>-CERN-CERN=.
</noautolink>

---+++ 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@cern.ch for the fix.





-----
Last edit: %SEARCH{".*" nosearch="on" regex="on" scope="title" nototal="no" topic="%TOPIC%" format="$wikiusername on $date"}%

Maintainer: Main.PaoloTedesco
-----

Topic revision: r2 - 2008-01-15 - unknown

LCG Wikis

LCG Service
Coordination

LCG Grid
Deployment

LCG
Apps Area

Public webs

Welcome Guest

- Cern Search
- TWiki Search
- Google Search
LCG All webs

Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback