 |
 |
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 keener 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)