To close the loop here, a misconfiguration had crept into panda's
schedconfig for Lancaster. Strangely atlas production only became
sensitive to this with a new release of the pilot, which made it
suddenly appear.
The bug has been fixed and, hopefully, the shifters now know not to
annoy the sites on this error.
Cheers
Graeme
On Mon, Aug 18, 2008 at 5:35 PM, Graeme Stewart
<[log in to unmask]> wrote:
> Hi Matt
>
> I have to confess I'm struggling to understand what the problem is
> here. It may be a panda internals issue, though actually you look to
> be configured just like Glasgow, which is working fine. the only
> difference is that your old dCache is mentioned as an SE. However,
> this should not be used at all for stage-out.
>
> I can lcg-cr files into your atlasproddisk space token without trouble.
>
> Cheers
>
> Graeme
>
> PS. For DPM tokens and namespace are orthogonal, but that is not true
> of other SEs.
>
> On Mon, Aug 18, 2008 at 5:01 PM, Matt Doidge <[log in to unmask]> wrote:
>> Thanks for the tip Alessandra. My understanding of space tokens was
>> that they are independant of path in the srm namespace, that the
>> token- path mapping was all done for the sake of tidyness but not
>> enforced- data for the ATLASPRODDISK token doesn't have to go into
>> /atlas/atlasproddisk/ direcotry. But jobs tend to do it as it's tidy.
>>
>> I'm not having much luck digging up the panda settings for our site
>> (Peter's away on holiday and he handled the panda stuff, being an
>> atlas chap) so would appreciate a tip on where to look (or who to
>> ask). Our tokens look alright:
>> ################
>> # Space tokens #
>> ################
>> s_type -
>> s_token a8faaede-3f5a-4a4c-a2fc-1fb46b36f2fd
>> s_uid 0
>> s_gid 129
>> ret_pol _
>> ac_lat O
>> u_token ATLASPRODDISK
>> t_space 2048.0 GB
>> u_space 1997.27424991 GB
>> g_space 2048.0 GB
>> pool atlas
>> a_life 4496591
>> r_life 2147483647
>>
>> And the acls on the corresponding atlasproddisk directory look alright too:
>> # file: /dpm/lancs.ac.uk/home/atlas/atlasproddisk/
>> # owner: root
>> # group: atlas/Role=production
>> user::rwx
>> group::rwx #effective:rwx
>> group:atlas/Role=production:rwx #effective:rwx
>> mask::rwx
>> other::r-x
>> default:user::rwx
>> default:group::rwx
>> default:group:atlas/Role=production:rwx
>> default:mask::rwx
>> default:other::r-x
>>
>> and the exact directory they're tryign to copy to seems to exist fine
>> and has the acl:
>> dpns-getacl /dpm/lancs.ac.uk/home/atlas/atlasproddisk//users/pathena
>> # file: /dpm/lancs.ac.uk/home/atlas/atlasproddisk//users/pathena
>> # owner: /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart
>> # group: atlas/Role=production
>> user::rwx
>> group::rwx #effective:rwx
>> group:atlas/Role=production:rwx #effective:rwx
>> mask::rwx
>> other::r-x
>> default:user::rwx
>> default:group::rwx
>> default:group:atlas/Role=production:rwx
>> default:mask::rwx
>> default:other::r-x
>>
>> cheers,
>> Matt
>>
>> On 18/08/2008, Alessandra Forti <[log in to unmask]> wrote:
>>> Hi Matt,
>>>
>>> apparently other sites that had the same problem had the wrong path for
>>> the space tokens in panda. You should check those first.
>>>
>>> cheers
>>> alessandra
>>>
>>> Matt Doidge wrote:
>>>> Hello,
>>>> The panda monitoring site is being a bit flakey for me, I can't pull
>>>> the job information although I think it's going to the atlasproddisk
>>>> space token. Although if there was an attempt to write to a bogus path
>>>> wouldn't this be logged in the srmv2.2 logs?
>>>>
>>>> I'm going to try catch one of these jobs on the farm and see if I can
>>>> probe what it's trying to do.
>>>>
>>>> cheers,
>>>> Matt
>>>>
>>>> On 18/08/2008, Greig A. Cowan <[log in to unmask]> wrote:
>>>>
>>>>> Do you have anymore information? What path is it trying to write to and
>>>>> does that path actually exist?
>>>>>
>>>>> Cheers,
>>>>> Greig
>>>>>
>>>>> On 18/08/08 14:50, Matt Doidge wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Loads of atlas jobs are failing at our site with the error (from the
>>>>>> panda
>>>>>> monitor);
>>>>>> pilot: Put error: put_data destination path in SE not defined|Log put
>>>>>> error: put_data destination path in SE not defined
>>>>>>
>>>>>> A quick googling gives me no clues, and my logs show nothing. In fact
>>>>>> the
>>>>>> dpm monitoring (courtesy of Greig) shows no failures for the DN that the
>>>>>> failing jobs are running under. So it might not be a storage problem at
>>>>>> all, but I thought I'd try to rule out my dpm first.
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Matt
>>>>>>
>>>>> --
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Well you'll still need a tray
>>>
>>>
>>
>
>
>
> --
> Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
> Department of Physics and Astronomy, University of Glasgow, Scotland
>
--
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
Department of Physics and Astronomy, University of Glasgow, Scotland
|