Also, what does your gridftp.conf stuff look like? (Apparently, this
can happen with odd/small blocksizes?)
Sam
On 9 June 2015 at 11:39, Sam Skipsey <[log in to unmask]> wrote:
> Hi Ewan:
>
> Can you do a ps on your se and a disk server, and tell me what the
> gridftp process's command line looks like?
>
> Sam
>
> On 9 June 2015 at 11:05, Ewan MacMahon <[log in to unmask]> wrote:
>> So,
>>
>> We have this GGUS ticket from ATLAS about some of their storage tests failing:
>> https://ggus.eu/?mode=ticket_info&ticket_id=114156
>>
>> At first glance, it looks pretty straightforward - we're failing transfers with an error. However, I can't see any reason for it at our end - we have the files, their sizes and permissions all look OK, they're not all on a single server, we don't seem to be failing any transfers other than these tests, and if you drill all the way down to the FTS logs for one:
>>
>> https://fts-test04.gridpp.rl.ac.uk:8449/var/log/fts3/2015-06-08/t2se01.physics.ox.ac.uk__se2.grid.lebedev.ru/2015-06-08-0557__t2se01.physics.ox.ac.uk__se2.grid.lebedev.ru__233999995__0c03b396-0da3-11e5-9520-001dd8b71d7e
>>
>> it looks like this:
>>
>> Mon Jun 8 06:57:43 2015 INFO [1433743063318] BTH GSIFTP TRANSFER:ENTER (163.1.5.215:0) gsiftp://t2se45.physics.ox.ac.uk/t2se45.physics.ox.ac.uk:/dpm/pool1/atlas/2015-02-27/sonar.test.UKI-SOUTHGRID-OX-HEP_DATADISK.file5.rnd.119909127.0 => (193.232.69.150:0) gsiftp://se4.grid.lebedev.ru/se4.grid.lebedev.ru:/st42/atlas/2015-06-08/sonar.test.UKI-SOUTHGRID-OX-HEP_DATADISK.file5.rnd.10855795.0
>> Mon Jun 8 06:57:52 2015 INFO bytes: 15990784, avg KB/sec:3123, inst KB/sec:3123, elapsed:9
>> Mon Jun 8 06:57:57 2015 INFO bytes: 79953920, avg KB/sec:7808, inst KB/sec:12492, elapsed:14
>> Mon Jun 8 06:58:02 2015 INFO bytes: 192675840, avg KB/sec:12544, inst KB/sec:22016, elapsed:19
>> Mon Jun 8 06:58:07 2015 INFO bytes: 308543488, avg KB/sec:15065, inst KB/sec:22630, elapsed:24
>> Mon Jun 8 06:58:12 2015 INFO bytes: 424148992, avg KB/sec:16568, inst KB/sec:22579, elapsed:29
>> Mon Jun 8 06:58:17 2015 INFO bytes: 535560192, avg KB/sec:17433, inst KB/sec:21760, elapsed:34
>> Mon Jun 8 06:58:22 2015 INFO bytes: 604241920, avg KB/sec:16859, inst KB/sec:13414, elapsed:39
>> Mon Jun 8 06:58:27 2015 INFO bytes: 679477248, avg KB/sec:16588, inst KB/sec:14694, elapsed:44
>> Mon Jun 8 06:58:32 2015 INFO bytes: 782237696, avg KB/sec:16975, inst KB/sec:20070, elapsed:49
>> Mon Jun 8 06:58:37 2015 INFO bytes: 896532480, avg KB/sec:17510, inst KB/sec:22323, elapsed:54
>> Mon Jun 8 06:58:42 2015 INFO bytes: 966787072, avg KB/sec:17165, inst KB/sec:13721, elapsed:59
>> Mon Jun 8 06:58:48 2015 INFO bytes: 1034158080, avg KB/sec:16665, inst KB/sec:11748, elapsed:65
>> Mon Jun 8 06:58:54 2015 ERROR TRANSFER globus_ftp_client: the server responded with an error 500 500-Command failed. : globus_ftp_control_data_write failed. 500-[globus_ftp_control]:globus_l_ftp_control_data_eb_write() : cannot register a zero length message unless you are signifing eof. 500 End.
>> Mon Jun 8 06:58:54 2015 INFO Report FAILED back to the server
>> Mon Jun 8 06:58:54 2015 INFO Send monitoring complete message
>>
>> Which looks like it was working fine right up until it suddenly went splat for no obvious reason near the end. And I can lcg-cp the file off the SE perfectly OK.
>>
>> I'm really not sure what to even look at next - does anyone have any ideas?
>>
>> Ewan
|