 |
 |
Hi Albert, Our logs on griddev04 show: 190627 10:47:38 1815 XrootdXeq: arossi.23027:[log in to unmask] pub IPv4 login as c2b5adb2.0 190627 10:47:43 1815 ofs_stat: arossi.23027:[log in to unmask] Unable to locate /xrootd/atlas/tpctest/alr-fnal-junk-Thu.Jun.27.12:47:37.CDT.2019; no such file or directory 190627 10:48:05 1780 XrootdXeq: arossi.23027:[log in to unmask] disc 0:00:27 190627 10:48:05 3493 ofs_TPC: arossi.23027:[log in to unmask] /xrootd/atlas/tpctest/alr-fnal-junk-Thu.Jun.27.12:47:37.CDT.2019 Copy failed with return code 32 190627 10:48:05 1749 XrootdsendResp: arossi.23027:[log in to unmask] sync async resp aborted; user gone. Your log pretty much shows the same thing. My first thought is that the source and destination file paths are reversed. Though that would be quite strange. Andy On Thu, 27 Jun 2019, Albert Rossi wrote: > Hi Andy, > > > This is what is puzzling to me. > > > I am wondering what could be causing this error. This is delegated TPC from my FNAL server (fndcatemp1.fnal.gov:1094) to > > > root://griddev03.slac.stanford.edu:2094//xrootd/atlas/tpctest > > > It looks like the xrdcp client gets redirected from griddev03 to griddev04, and the file is opened there, but then it keeps stat'ing without any progress. > > I've attached the client log (killed after a minute or so). > > What I am seeing in the dCache door is a successful placement from the xrdcp client, but then silence. > > Could it be there is some network issue preventing your backend from reaching fndcatemp1.fnal.gov:1094? > > (I am using my development machine machine rather than the WLCG-DOMA FNAL endpoint because I have more control over it, can stop, start, etc. as I see fit, and the logging is limited to my own activity rather than the constant bombardment from the WLCG testing). > > -Al > > _____________________________________________ > Albert L. Rossi > Application Developer & Systems Analyst III > Scientific Computing Division, Data Movement Development > FCC 229A > Mail Station 369 (FCC 2W) > Fermi National Accelerator Laboratory > Batavia, IL 60510 > (630) 840-3023 > ________________________________ > From: Andrew Hanushevsky <[log in to unmask]> > Sent: Thursday, June 27, 2019 12:21:09 PM > To: Albert Rossi > Cc: [log in to unmask] > Subject: Re: question about errors > > Hi Albert, > > All SLAC servers export data read-onlyand the copy istrying to openthe > file in write mode. The message should be taken on face value. The head > node couldn't find any server that would allow writes. > > Andy > > On Thu, 27 Jun 2019, Albert Rossi wrote: > >> Hi, >> >> >> I have been working on a "smoke test" suite in python and have started to do a little testing between endpoints. >> >> >> I was wondering if you could give me some indication of possible causes when the following error is received from the SLAC server. >> >> >> [3011] No servers have write access to the file >> >> >> This seems to occur at the SLAC WLCG-DOMA endpoint when my testbed machine is the SOURCE in a TPC. >> >> >> Any ideas? >> >> >> Thanks, Al >> >> >> ________________________________________________ >> Albert L. Rossi >> Application Developer & Systems Analyst III >> Scientific Computing Division, Data Movement Development >> FCC 229A >> Mail Station 369 (FCC 2W) >> Fermi National Accelerator Laboratory >> Batavia, IL 60510 >> (630) 840-3023 >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DL-26A-3D1&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=7lNJKye4q1RFFc7TQ0u_KbvvA5ZWvMF52UNaqjGwSW8&s=d5QjtfUxegp9xm0SvZNOTwyWJZCHmcnUAe-OpH8J6x4&e= >> > ######################################################################## 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