 |
 |
On 30 Mar 2016, at 09:02, Elena Korolkova <[log in to unmask]> wrote: > Good morning, > > I decided to try rfcp command again. > > rfcp ./atlasscratchdisk-dump_20160328 /dpm/shef.ac.uk/home/atlas/atlasscratchdisk/dumps/dump_20160328 which is failed with error: > >> *** buffer overflow detected ***: rfcp terminated >> ======= Backtrace: ========= >> /lib64/libc.so.6(__fortify_fail+0x37)[0x34c5502567] >> /lib64/libc.so.6[0x34c5500450] >> rfcp[0x401f61] >> /lib64/libc.so.6(__libc_start_main+0xfd)[0x34c541ed5d] >> rfcp[0x401319] > > I thought the problem /lib64/libc.so.6(__fortify_fail+0x37) can be related to old kernel so I rebooted the head node to pick up a new one. > After reboot I ‘ve tried rfcp command again. It failed with the the same error message. I’ve checked the log files on a head nod: > > dpm/log: > /var/log/dpm/log-03/30 08:18:46.523 10168,3 dpm_srv_put: DP092 - put request by /C=UK/O=eScience/OU=Sheffield/L=CICS/CN=lcgse0.shef.ac.uk (0,0) from lcgse0.shef.ac.uk > /var/log/dpm/log-03/30 08:18:46.541 10168,3 dpm_srv_put: DP098 - put 99105460 4b71e99e-a755-4577-be40-f5607219ec7d > /var/log/dpm/log:03/30 08:18:46.541 10168,3 dpm_srv_put: DP098 - put 0 /dpm/shef.ac.uk/home/atlas/atlasscratchdisk/dumps/dump_20160328 > /var/log/dpm/log-03/30 08:18:46.564 10168,3 dpm_serv: incrementing reqctr > /var/log/dpm/log-03/30 08:18:46.564 10168,3 dpm_serv: msthread signalled > /var/log/dpm/log-03/30 08:18:46.564 10168,3 dpm_srv_put: returns 0, status=DPM_QUEUED > > /var/log/dpm/log-03/30 08:18:46.710 10168,63 dpm_selectfs: lcgse1.shef.ac.uk:/storage reqsize=209715200, elemp->free=1326969341528, poolp->free=16366841870809 > /var/log/dpm/log-03/30 08:18:47.304 10168,63 dpm_srv_proc_put: calling Cns_creatx > /var/log/dpm/log:03/30 08:18:47.531 10168,63 dpm_srv_proc_put: TURL info: rfio lcgse1.shef.ac.uk lcgse1.shef.ac.uk:/storage/root/2016-03-30/dump_20160328.99105460.0 > /var/log/dpm/log-03/30 08:18:47.540 10168,63 dpm_srv_proc_put: returns 0, status=DPM_SUCCESS > > on se1, rfio/log: > Mar 30 08:18:49 rfiod[27200]: request by /C=UK/O=eScience/OU=Sheffield/L=CICS/CN=lcgse0.shef.ac.uk (151,151) > Mar 30 08:18:49 rfiod[27200]: ropen64_v3: (/storage/root/2016-03-30/dump_20160328.99105460.0,01401,0644) for (151,151) > Mar 30 08:18:49 rfiod[27200]: ropen64_v3: assigning data port 20523 > Mar 30 08:18:49 rfiod[27200]: close_socket(5): 0 read, 0 readahead, 0 write, 0 flush, 0 stat, 0 lseek and 0 lockf > Mar 30 08:18:49 rfiod[27200]: close_socket(5): 0 bytes read and 0 bytes written > Mar 30 08:18:49 rfiod[27200]: connection 5 dropped by remote end > Mar 30 08:18:49 rfiod[27200]: Closing socket fildesc=5 > > Apparently, the dump is tried to be copy in lcgse1.shef.ac.uk:/storage/root/2016-03-30/dump_20160328.99105460.0, not to lcgse1.shef.ac.uk:/storage/atlas/2016-03-30/dump_20160328.99105460.0. > > Any thoughts will be much appreciated. > > Unfortunately, I can’t join the storage meeting today as I have an appointment. > > Thank you very much. > > Elena > > > > On 29 Mar 2016, at 19:46, Alessandra Forti <[log in to unmask]> wrote: > >> Hi, >> >> I wonder if in the lcgdm-mapfile-local the . shouldn't be removed from .atlas >> >> cheers >> alessandra >> >> On 29/03/2016 18:54, Elena Korolkova wrote: >>> Thank you very much, Simon >>> >>> Elena >>> >>> On 29 Mar 2016, at 18:49, George, Simon<[log in to unmask]> wrote: >>> >>>> Hi Elena, >>>> For example: >>>> >>>> dpns-mkdir -p /dpm/ppgrid1.rhul.ac.uk/home/atlas/atlasdatadisk/dumps >>>> dpns-setacl -m g:atlas:rwx,m:rwx /dpm/ppgrid1.rhul.ac.uk/home/atlas/atlasdatadisk/dumps >>>> xrdcp ./atlasdatadisk-dump_20160317 root://se2.ppgrid1.rhul.ac.uk//dpm/ppgrid1.rhul.ac.uk/home/atlas/atlasdatadisk/dumps/dump_20160317 >>>> >>>> It is straight from the ATLAS script. I don't think I changed it. >>>> Simon >> >> -- >> Respect is a rational process. \\// >> Fatti non foste a viver come bruti (Dante) >