Hi Brian,
As I replied in GGUS ticket
(https://gus.fzk.de/ws/ticket_info.php?ticket=37669) we looked into
the problem and found that the files you are trying to copy are lost.
It did exist in the pnfs file system however had zero length and no
information what pool does host it. As this is useless we have had to
delete it completely and I'm afraid there is no way to restore it
since we had no replica manager running on dcache01 at the time the
file was created (12/06/2008) and there is no copy of the file in our
system.
As you know dcache01 was in unstable condition in a past few months
having been upgraded, reconfigured, restarted many times. During this
time some information (apparently without replica) might be lost.
Please accept our apology.
Now the system has replica manager running and is in more stable
condition. We hope this will not happen again.
As for srm2.2 use this endpoint:
sergey@niels005:~$ /opt/d-cache/srm/bin/srmping -debug=true
-srm_protocol_version=2
srm://dcache01.tier2.hep.manchester.ac.uk:8443/pnfs/tier2.hep.manchester.ac.uk/
Storage Resource Manager (SRM) CP Client version 2.0
Copyright (c) 2002-2006 Fermi National Accelerator Laboratory
SRM Configuration:
debug=true
gsissl=true
help=false
pushmode=false
userproxy=true
buffer_size=131072
tcp_buffer_size=0
streams_num=10
config_file=config.xml
glue_mapfile=conf/SRMServerV1.map
webservice_path=srm/managerv2
webservice_protocol=https
gsiftpclinet=globus-url-copy
protocols_list=http,gsiftp
save_config_file=null
srmcphome=..
urlcopy=sbin/urlcopy.sh
x509_user_cert=/home/timur/k5-ca-proxy.pem
x509_user_key=/home/timur/k5-ca-proxy.pem
x509_user_proxy=/tmp/x509up_u508
x509_user_trusted_certificates=/etc/grid-security/certificates
globus_tcp_port_range=null
gss_expected_name=null
storagetype=permanent
retry_num=20
retry_timeout=10000
wsdl_url=null
use_urlcopy_script=false
connect_to_wsdl=false
delegate=true
full_delegation=true
server_mode=passive
srm_protocol_version=2
request_lifetime=86400
access latency=null
overwrite mode=null
priority=0
Thu Jun 26 09:55:23 BST 2008: In SRMClient ExpectedName: host
Thu Jun 26 09:55:23 BST 2008: SRMClient(https,srm/managerv2,true)
SRMClientV2 : user credentials are:
/C=UK/O=eScience/OU=Manchester/L=HEP/CN=sergey dolgobrodov
SRMClientV2 : WEBSERVICE_PATH srm/managerv2
SRMClientV2 : connecting to srm at
httpg://dcache01.tier2.hep.manchester.ac.uk:8443/srm/managerv2
SRMClientV2 : srmPing , contacting service
httpg://dcache01.tier2.hep.manchester.ac.uk:8443/srm/managerv2
Thu Jun 26 09:55:26 BST 2008: received response
Thu Jun 26 09:55:26 BST 2008: VersionInfo : v2.2
backend_type:dCache
backend_version:production-1-8-0-15p5
Regards
Sergey
2008/6/26 brian davies <[log in to unmask]>:
> Manchester are not publishing an srmv2.2 endpoint? is this currently expected?
> Also for ATLAS,this file
> srm://dcache01.tier2.hep.manchester.ac.uk/pnfs/tier2.hep.manchester.ac.uk/data/atlas/valid2/log/valid2.008801
> .Hijing_PbPb_5p5TeV_MinBias.digit.log.e113_s417_tid022721/log.022721._10929.job.log.tgz.2
> is being tried to copy to
>
> srm://srm-atlas.gridpp.rl.ac.uk:8443/srm/managerv2?SFN=/castor/ads.rl.ac.uk/prod/atlas/simStrip/atlasmcdisk/v
> alid2/log/valid2.008801.Hijing_PbPb_5p5TeV_MinBias.digit.log.e113_s417_tid022721_sub01924052/log.022721._1092
> 9.job.log.tgz.2__DQ2-1214466304
>
> That might not seem strange, apart from it has failed 3406 times!!! So
> ATLAS will probably have to look at th eretry policy, but can you
> access the file on your dcache?
> Also I am unable to copy the file to file://// using srmcp ( goes into
> sleeping cycle)
>
> Brian
>
