Print

Print


Hi Nikolai,

An expired CRL could cause the xrootd client to fail to fetch data from the remote data source.  So I think the two issue could be related.

when you use gLFN: root://xcache//altas/rucio/scope:file, the plugin recognize that this is a gLFN (because of /atlas/rucio) and will query RUCIO for all available data sources (and save it to a metalink).

when you use root://xcache//root://data_source.com//dir/file, the plugin assume that you only want to use file from "data_source.com". it won't query RUCIO for other data sources. It will simply create a metalink with just that data source.

Could this be related to your second issue?

regards,
--
Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)
 

On 3/2/20, 6:25 AM, "Nikolai Hartmann" <[log in to unmask]> wrote:

    Hi Wei,
    
    Sorry for the long silence - almost forgot that problem. It seems that
    this problem is sometimes (not always) accompanied by a log message like
    this:
    
    ... secgsi_GetCACheck: CRL entry for '...' needs refreshing: clean the
    related entry cache first (...)
    
    Can this be related?
    
    Also, it seems in case the file has replicas at another site i also
    can't access those via xcache. For example currently all of the
    following give me an error (but i can download directly via xrdcp when
    not going through xcache)
    
    xrdcp -v
    root://lcg-lrz-xcache1.grid.lrz.de:1094//root://dcache-atlas-xrootd.desy.de:1094//pnfs/desy.de/atlas/dq2/atlasdatadisk/rucio/data18_13TeV/4e/57/data18_13TeV.00349263.physics_Main.merge.AOD.f937_m1972._lb0149._0001.1
    .
    
    xrdcp -v
    root://lcg-lrz-xcache1.grid.lrz.de:1094//root://t2-dpm-01.na.infn.it:1094//dpm/na.infn.it/home/atlas/atlasdatadisk/rucio/data18_13TeV/4e/57/data18_13TeV.00349263.physics_Main.merge.AOD.f937_m1972._lb0149._0001.1
    .
    
    xrdcp -v
    root://lcg-lrz-xcache1.grid.lrz.de:1094//root//griddev03.slac.stanford.edu:2094//xrootd/atlas/atlasdatadisk/rucio/data18_13TeV/4e/57/data18_13TeV.00349263.physics_Main.merge.AOD.f937_m1972._lb0149._0001.1
    .
    
    So in this case it doesn't seem to be a data source problem.
    
    Cheers,
    Nikolai
    
    On 12/13/19 6:24 PM, Yang, Wei wrote:
    > Hi Nikolai,
    > 
    > Unfortunately your example using xrdcp just demonstrated that the site wasn't giving you the file (I just tried and it is working now). The meta4 and the URL inside were created unconditionally so it is not surprised they were correct. Usually it is the xrootd client component that runs into trouble, including unable to start a thread (such as process or file descriptor limits are reached), doesn't have a valid X509 proxy, remote sites doesn’t work, etc. 
    > 
    > Does these happen to several files at the same time? Otherwise it is hard to tell from the log whether this is a data source problem or Xcache problem.
    > 
    > regards,
    > --
    > Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)
    >  
    > 
    > On 12/13/19, 2:37 AM, "Nikolai Hartmann" <[log in to unmask]> wrote:
    > 
    >     Hi,
    >     
    >     We occasionally get an error when we try to load ATLAS files via our
    >     xcache server that are available when we download them directly. For
    >     example currently:
    >     
    >     xrdcp -v
    >     root://lcg-lrz-xcache1.grid.lrz.de:1094//root://lcg-se01.icepp.jp:1094//dpm/icepp.jp/home/atlas/atlasdatadisk/rucio/data18_13TeV/54/b0/data18_13TeV.00349169.physics_Main.merge.AOD.f937_m1972._lb0658._0002.1
    >     .
    >     [0B/0B][100%][==================================================][0B/s]
    >     Run: [ERROR] Server responded with an error: [3011] Unable to open
    >     /root:/lcg-se01.icepp.jp:1094/dpm/icepp.jp/home/atlas/atlasdatadisk/rucio/data18_13TeV/54/b0/data18_13TeV.00349169.physics_Main.merge.AOD.f937_m1972._lb0658._0002.1;
    >     no such file or directory
    >     
    >     We use the rucioN2N plugin. The metalink file seems to be created and
    >     contain the correct url.
    >     I attached the parts of the xrootd logfile around this.
    >     Last time this was resolved by restarting xrootd - at that time we had
    >     the issue that many file descriptors were open. This time this seems not
    >     to be the case.
    >     
    >     Any ideas how to debug this further?
    >     
    >     Thanks,
    >     Nikolai
    >     
    >     
    > 
    > 
    > ########################################################################
    > Use REPLY-ALL to reply to list
    > 
    > To unsubscribe from the XROOTD-L list, click the following link:
    > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
    > 
    


########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1