Hi
Well its possible that you just don't have those files that are being requested (its unfortunate I think that it says "error" for that) .
Anyway - while you are looking at it - you may as well go straight to the newest N2N library from here
http://git.cern.ch/pubweb/FAX.git/tree/HEAD:/N2N/cPlusPlus/RPM
But then you need to change the configuration following
>>> https://svnweb.cern.ch/trac/lcgdm/wiki/Dpm/Xroot/Setup
>>>
>>> specifically the changes are (in Yaim)
>>>
>>> DPM_XROOTD_FED_ATLAS_NAMELIB="XrdOucName2NameLFC.so root=/dpm/<dpm domain>/home/atlas match=dpm-srm-host.example.com <http://dpm-srm-host.example.com> pssorigin=localhost rucioprefix=/dpm/<dpm domain>/home/atlas/atlasdatadisk,/dpm/<dpm domain>/home/atlas/atlasgroupdisk/soft-test,/dpm/<dpm domain>/home/atlas/atlasscratchdisk,/dpm/<dpm domain>/home/atlas/atlasproddisk,/dpm/<dpm domain>/home/atlas/atlasgroupdisk/phys-sm,/dpm/<dpm domain>/home/atlas/atlasgroupdisk/perf-idtracking,/dpm/<dpm domain>/home/atlas/atlaslocalgroupdisk,/dpm/<dpm domain>/home/atlas/atlashotdisk"
>>>
>>> so you need to give to rucioprefix a comma seperated list of all of you
>>> spacetokens
I attach the email from David Smith explaining this parameters - that I thought I had forwarded before but maybe that was to an atlas list.
You could actually also try the auto rucio path setup option that he mentions (ie.
pssorigin=localhost sitename= UKI-NORTHGRID-LANCS-HEP_SL6
)
to see if it works. I thought I tried this at Edinburgh but now I am not so sure.
Maybe we should debug that option more as it would certainly save the hassle of maintaining this list of paths.
Cheers
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
Wahid
On 31 Oct 2013, at 16:26, Matt Doidge <[log in to unmask]> wrote:
> Hello
>>> however your Fax redirector is not working now according to SSB. Did
>>> it start up OK ?
>>>
>>
>> It looks like it did, but I see lots of "XRD-LFC No such file or
>> directory" and "N2N error" messages in the fedredir_atlas/xrootd.log, so
>> things aren't happy.
>>
>> My reluctance to run yaim may have screwed the pooch somewhere.
>
> I've re-manually configured our xrootd server, and whilst it appears to be working directly the atlas redirector still isn't playing ball, with lots of messages like:
>
> 131031 16:20:56 0x76ed3700 XRD-LFC: lookup /atlas/dq2/mc12_8TeV/HITS/e2356_s1581/mc12_8TeV.201020.AlpgenAutoPythia_P2012_ttbar_lnlnNp0.simul.HITS.e2356_s1581_tid01352548_00/HITS.01352548._031142.pool.root.1
> 131031 16:20:56 0x76ed3700 XRD-LFC No such file or directory /atlas/dq2/mc12_8TeV/HITS/e2356_s1581/mc12_8TeV.201020.AlpgenAutoPythia_P2012_ttbar_lnlnNp0.simul.HITS.e2356_s1581_tid01352548_00/HITS.01352548._031142.pool.root.1
> 131031 16:20:56 0x76ed3700 XRD-LFC No such file or directory /grid/atlas/dq2/mc12_8TeV/HITS/e2356_s1581/mc12_8TeV.201020.AlpgenAutoPythia_P2012_ttbar_lnlnNp0.simul.HITS.e2356_s1581_tid01352548_00/HITS.01352548._031142.pool.root.1
> 131031 16:20:56 0x76ed3700 XRD-LFC: no valid replica for /atlas/dq2/mc12_8TeV/HITS/e2356_s1581/mc12_8TeV.201020.AlpgenAutoPythia_P2012_ttbar_lnlnNp0.simul.HITS.e2356_s1581_tid01352548_00/HITS.01352548._031142.pool.root.1
> 131031 16:20:56 12637 dpmfinder_Locate: [#01.000002] N2N error
>
> in the fedredir xrootd.log
>
> I've checked the crazy atlas N2N lib that we had to install when we rolled out xrootd is still in place, I updated it to the latest version (didn't help, but didn't break anything, but is it the problem to start with?). The LFC settings in our configs seem correct, unless I missed a memo somewhere (LFC_HOST=prod-lfc-atlas-ro.cern.ch).
>
> Any help appreciated.
> Matt
>
>
>
>
>>
>> Cheers,
>> Matt
>>
>>> Also Liv, Man and Ox don't seem to have restarted since the issue I
>>> raised a couple of days ago (if you did and its stuck again then
>>> please do send me the log ) .
>>>
>>> Cheers
>>>
>>> Wahid
>>> On 30 Oct 2013, at 17:56, Matt Doidge <[log in to unmask]> wrote:
>>>
>>>> A quick update to this, after updating to 1.8.7 and running a few of
>>>> the post-update workarounds for problems here:
>>>> https://www.gridpp.ac.uk/wiki/DPMUpgradeTips
>>>>
>>>> The problem just evapourated, the local user can access their files
>>>> though xrootd with no problem.
>>>>
>>>> I'd like to say that's just what I intended to happen, but I'd be a
>>>> liar!
>>>>
>>>> Have a good evening all,
>>>> Matt
>>>>
>>>> On 10/30/2013 10:01 AM, Matt Doidge wrote:
>>>>> Hello,
>>>>> One of our local atlas users has been trying to access his data on our
>>>>> SE using xrdcp, which should be fine. But he got permission denied
>>>>> errors to read the date. Peter tried the same, and got the same error -
>>>>> except when he tried it with an atlas production proxy. Then it worked.
>>>>>
>>>>> Looks like my acls are screwed up (or something along those lines), but
>>>>> I can't figure out what's up. I could understand problems if the user
>>>>> was trying to write, but he was just trying to "xrdcp -f" files to his
>>>>> local box.
>>>>>
>>>>> # dpns-getacl
>>>>> /dpm/lancs.ac.uk/home/atlas/atlasscratchdisk/rucio/user/jwalder/fb/59/
>>>>> # file:
>>>>> /dpm/lancs.ac.uk/home/atlas/atlasscratchdisk/rucio/user/jwalder/fb/59/
>>>>> # owner: /DC=ch/DC=cern/OU=Organic
>>>>> Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management
>>>>> # group: atlas/Role=production
>>>>> user::rwx
>>>>> group::rwx #effective:rwx
>>>>> group:atlas:rwx #effective:rwx
>>>>> group:atlas/Role=production:rwx #effective:rwx
>>>>> mask::rwx
>>>>> other::r-x
>>>>> default:user::rwx
>>>>> default:group::rwx
>>>>> default:group:atlas:rwx
>>>>> default:group:atlas/Role=production:rwx
>>>>> default:mask::rwx
>>>>> default:other::rwx
>>>>>
>>>>> # dpns-ls -ld
>>>>> /dpm/lancs.ac.uk/home/atlas/atlasscratchdisk/rucio/user/jwalder/fb/59/
>>>>> drwxrwxr-x 0 1171 129 0 Oct 23 22:16
>>>>> /dpm/lancs.ac.uk/home/atlas/atlasscratchdisk/rucio/user/jwalder/fb/59/
>>>>>
>>>>> # dpns-listgrpmap | grep 129
>>>>> 129 atlas/Role=production
>>>>>
>>>>> # dpns-listusrmap | grep 1171
>>>>> 1171 /DC=ch/DC=cern/OU=Organic
>>>>> Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management
>>>>>
>>>>> Any help appreciated!
>>>>> Cheers,
>>>>> Matt
>>>>
>>>
>>>
>
|
