Hm, okay, so I think you're probably correct in blaming dpm-dsi as you
do in the dpm-user-forum post. Are you getting failures for protocols
other than gridftp? (What does xrootd look like?)
Sam
On 27 October 2015 at 10:36, John Hill <[log in to unmask]> wrote:
> Hi Sam,
> The only file in /etc/dmlite.conf.d/ is adapter.conf and the contents are
> identical to those on a working node:
>
> LoadPlugin plugin_adapter_dpm /usr/lib64/dmlite/plugin_adapter.so
> LoadPlugin plugin_fs_rfio /usr/lib64/dmlite/plugin_adapter.so
> DpmHost serv02.hep.phy.cam.ac.uk
> TokenPassword XXXXXXXXXXXXXXXXXXXXXX
> TokenId ip
> TokenLife 1000
>
> John
>
>
> On 27/10/2015 10:29, Sam Skipsey wrote:
>>
>> Hi John:
>>
>> Those errors are from the dmlite adaptor, I think. What config files
>> do you have in /etc/dmlite.conf.d/ and what is their contents?
>> (Compare with a working node if possible).
>>
>> Sam
>>
>> On 26 October 2015 at 17:32, John Hill <[log in to unmask]> wrote:
>>>
>>> Sorry, it's been a long day :-( The log file in question is of course
>>> gridftp.log
>>>
>>> John
>>>
>>>
>>> On 26/10/2015 17:09, John Hill wrote:
>>>>
>>>>
>>>> Afternoon,
>>>> This afternoon I decided to bite the bullet and try updating a pool
>>>> node to dpm 1.8.10. The update generally appears OK, though I still have
>>>> some major puppet issues to sort out. However, gridftp transfers are now
>>>> failing the checksum update. dpm-gsiftp.log contains entries like
>>>>
>>>> [3451] Mon Oct 26 17:01:03 2015 :: dmlite :: checksum :: failed to
>>>> update
>>>> [3451] Mon Oct 26 17:01:03 2015 :: dmlite :: user error :: 22(22) ::
>>>> [#00.000022] Invalid argument: :: /DC=ch/DC=cern/OU=Organic
>>>> Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management ::
>>>> fts-test03.gridpp.rl.ac.uk
>>>>
>>>> Any suggestions as to what I need to tweak are welcome.
>>>>
>>>> John
|