On 5 Jul 2006, at 20:05, Dr D J Colling wrote:
> Dear *,
>
> I have been having problems trying to copy some test files to
> Brunel and I suspect that I am doing something wrong and it is my
> ingnorance so any advice would be useful.
>
> So first I try:
>
> glite-transfer-submit -p mypassword -f tt
>
> where tt contains
>
> srm://dcache.gridpp.rl.ac.uk:8443/srm/managerv1?SFN=/pnfs/
> gridpp.rl.ac.uk/data/cms/phedex_loadtest/LoadTest_T1_RAL_030 srm://
> dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test
>
> The endpoint at Brunel I got from their ldap.
>
> Initial the transfer becomes active and an srm-get-metadata returns
> reasonable values however eventually the copy fails and a glite-
> transfer-status gives
> Failed
> Source: srm://dcache.gridpp.rl.ac.uk:8443/srm/managerv1?SFN=/pnfs/
> gridpp.rl.ac.uk/data/cms/phedex_loadtest/LoadTest_T1_RAL_030
> Destination: srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/
> home/cms/DJC_test/test
> State: Failed
> Retries: 4
> Reason: Transfer failed. ERROR the server sent an error
> response: 425 425 Can't open data connection. timed out() failed.
>
> Duration: 0
>
>
> and the get-metadata says that there is no file there (which there
> isn't). Am I doing something stupid?
>
> All the best,
> david
I don't think so...
I have checked that I can srmcp a file into Brunel, so that much at
least works:
grid13:~$ srmcp -debug=true file:////etc/group srm://dgc-
grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/dteam/gs_test_20060705
Then:
grid13:~$ edg-gridftp-ls --verbose gsiftp://dgc-grid-34.brunel.ac.uk:
2811/dpm/brunel.ac.uk/home/dteam
...
-rw-rw-r-- 1 ops013 dteam 520 Jul 05 21:14
gs_test_20060705
...
Note the rather odd UID mapping to ops. I also see that with your
test directory:
grid13:~$ edg-gridftp-ls --verbose gsiftp://dgc-grid-34.brunel.ac.uk:
2811/dpm/brunel.ac.uk/home/cms
drwxrwxr-x 0 ops012 cms 0 Jul 05 18:36
DJC_test
Which indicates we're being rather aggressively mapped to the ops VO.
I also checked that I could get your source file out of RALs dCache
and that worked.
Then, trying an FTS transfer,
grid13:~$ glite-transfer-submit srm://dcache.gridpp.rl.ac.uk:8443/
pnfs/gridpp.rl.ac.uk/data/dteam/tfr2tier2/canned10M srm://dgc-
grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/dteam/
gs_test_20060705-fts-wee
Gets to:
grid13:~$ glite-transfer-status -l bea0acdc-0c66-11db-b679-e8890ecfc30e
Done
Source: srm://dcache.gridpp.rl.ac.uk:8443/pnfs/
gridpp.rl.ac.uk/data/dteam/tfr2tier2/canned10M
Destination: srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/
home/dteam/gs_test_20060705-fts-wee
State: Done
Retries: 0
Reason: (null)
Duration: 0
So that looks ok.
The trying your file:
grid13:~$ glite-transfer-submit srm://dcache.gridpp.rl.ac.uk:8443/
pnfs/gridpp.rl.ac.uk/data/cms/phedex_loadtest/LoadTest_T1_RAL_030
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/dteam/
gs_test_20060705-fts
It's active, and seems to be ok (although 1.7GB to Brunel will take a
while...)
I suspect something might be up with CMS transfers in particular. Can
you try a simple srmcp and check that that works. And are you mapped
to some odd ops person?
Perhaps Duncan or Henry could check the DPM mapping file.
And, Matt, I can't see anything for the BRUNEL channel on the
server's logs:
https://lcgfts.gridpp.rl.ac.uk:8443/glite-data-transfer-fts/fts-logs/
var/log/glite/
Just an old logfile for glite-transfer-channel-agent-urlcopy-RALLCG2-
UKILT2BRUNEL.log.1
Cheers
Graeme
--
Dr Graeme Stewart - http://wiki.gridpp.ac.uk/wiki/User:Graeme_stewart
GridPP DM Wiki - http://wiki.gridpp.ac.uk/wiki/Data_Management
|