Hi managers,
I tried to sync from msync.centos.org , but some time, it will point to centosg9.centos.org (103.232.121.196), and will try to sync a dirty file "7.7.1908/isos/x86_64/.CentOS-7-x86_64-Everything-1908.iso.RjFDl5".
Please check it, thanks.
Fulong Sun
On 25/05/2020 11:20, sfl@neusoft.edu.cn wrote:
Hi managers
I tried to sync from msync.centos.org , but some time, it will point to centosg9.centos.org (103.232.121.196), and will try to sync a dirty file “7.7.1908/isos/x86_64/.CentOS-7-x86_64-Everything-1908.iso.RjFDl5".
Thanks for the notification,
We had indeed some issues with that particular nodes so it seems that some files were left behind after 7.7.1908 was archived to vault.centos.org. I checked on that node and today those files were gone, so should be already good
Cheers,
Hi Fabian,
This time, is centosx4.centos.org, it has a .~tmp~ directory under 8.1.1911/AppStream/aarch64/os/Packages/, could you check it?
-----Original Message----- From: CentOS-mirror centos-mirror-bounces@centos.org On Behalf Of Fabian Arrotin Sent: 2020年5月26日 20:00 To: centos-mirror@centos.org Subject: Re: [CentOS-mirror] Dirty file on server
On 25/05/2020 11:20, sfl@neusoft.edu.cn wrote:
Hi managers
I tried to sync from msync.centos.org , but some time, it will point to centosg9.centos.org (103.232.121.196), and will try to sync a dirty file “7.7.1908/isos/x86_64/.CentOS-7-x86_64-Everything-1908.iso.RjFDl5".
Thanks for the notification,
We had indeed some issues with that particular nodes so it seems that some files were left behind after 7.7.1908 was archived to vault.centos.org. I checked on that node and today those files were gone, so should be already good
Cheers,
On Sat, 30 May 2020, sfl@neusoft.edu.cn wrote:
This time, is centosx4.centos.org, it has a .~tmp~ directory under 8.1.1911/AppStream/aarch64/os/Packages/, could you check it?
Ahh, isn't this "normal" behaviour, showing that an upstream sync was in progress? Having approriate rsync option (like --delay-updates or something like that) should take care of this, both at centosx4 and the downstream mirror, no?
Hi Sriram,
I believe, it's must something wrong, either that server or mine, could you help me to identify it?
First, I think the .~tmp~ directory is private, shouldn't in downstream sync list, and Second, in China, the sync speed is very slow (under 100KB/s at most time), and the .~tmp~ has huge size (many GB), will cause too many days to sync, and after, useless.
This issue only happen when I sync from the centosx4 server, I had to terminated it manual each time, or waste days time.
My sync script: rsync -4aHvP --delete-delay --timeout=90 msync.centos.org::CentOS /var/www/mirrors.neusoft.edu.cn/htdocs/centos/
How can I modify it to make it better?
-----Original Message----- From: CentOS-mirror centos-mirror-bounces@centos.org On Behalf Of Prof. P. Sriram Sent: 2020年5月30日 22:57 To: Mailing list for CentOS mirrors. centos-mirror@centos.org Subject: Re: [CentOS-mirror] Dirty file on server
On Sat, 30 May 2020, sfl@neusoft.edu.cn wrote:
This time, is centosx4.centos.org, it has a .~tmp~ directory under 8.1.1911/AppStream/aarch64/os/Packages/, could you check it?
Ahh, isn't this "normal" behaviour, showing that an upstream sync was in progress? Having approriate rsync option (like --delay-updates or something like that) should take care of this, both at centosx4 and the downstream mirror, no?
Hi!
Maybe can help you:
1. exclude all temporary files/dirs, when rsync'inc like
My sync script: rsync -4aHvP --delete-delay --timeout=90 msync.centos.org::CentOS /var/www/mirrors.neusoft.edu.cn/htdocs/centos/
rsync -4aHvP --exclude='*/.~tmp~' --delete-delay --timeout=90 msync.centos.org::CentOS /var/www/mirrors.neusoft.edu.cn/htdocs/centos/
2. To autoterminate rsync process use "timeout" like: timeout --preserve-status --kill-after=15 7200 rsync -4aHvP --exclude='*/.~tmp~' --delete-delay --timeout=90 msync.centos.org::CentOS /var/www/mirrors.neusoft.edu.cn/htdocs/centos/
here "timeout" send to rsync process SIGTERM signal immediately after 7200 seconds after run. AND also SIGKILL signal after 15 seconds from previous (normal SIGTERM) signal (killing controlled process, if not terminated by signal).
Sure, insert correct _FOR_YOUR_ timers.
3. Maybe, some reason for rsync'ing from nearest/fastest (FOR_YOU) mirror (other China mirror / other Asia mirror)?
Have a nice day!
18.06.20 01:15, sfl@neusoft.edu.cn пише:
Hi Sriram,
I believe, it's must something wrong, either that server or mine, could you help me to identify it?
First, I think the .~tmp~ directory is private, shouldn't in downstream sync list, and Second, in China, the sync speed is very slow (under 100KB/s at most time), and the .~tmp~ has huge size (many GB), will cause too many days to sync, and after, useless.
This issue only happen when I sync from the centosx4 server, I had to terminated it manual each time, or waste days time.
My sync script: rsync -4aHvP --delete-delay --timeout=90 msync.centos.org::CentOS /var/www/mirrors.neusoft.edu.cn/htdocs/centos/
How can I modify it to make it better?
-----Original Message----- From: CentOS-mirror centos-mirror-bounces@centos.org On Behalf Of Prof. P. Sriram Sent: 2020年5月30日 22:57 To: Mailing list for CentOS mirrors. centos-mirror@centos.org Subject: Re: [CentOS-mirror] Dirty file on server
On Sat, 30 May 2020, sfl@neusoft.edu.cn wrote:
This time, is centosx4.centos.org, it has a .~tmp~ directory under 8.1.1911/AppStream/aarch64/os/Packages/, could you check it?
Ahh, isn't this "normal" behaviour, showing that an upstream sync was in progress? Having approriate rsync option (like --delay-updates or something like that) should take care of this, both at centosx4 and the downstream mirror, no?
Mirror went off line last year, is back on line now, requesting re-enabling of listing, details as below, thanks.
Sriram
————————————— mirror details ———————————
HTTP: http://ftp.iitm.ac.in/centos HTTPS: --- RSYNC: rsync://ftp.iitm.ac.in/centos
Sync schedule: Every 3 hrs Bandwidth: 10 GBPS Location: India Sponsor: Indian Institute of Technology Madras Sponsor URL: http://www.iitm.ac.in IPv4 address to authorize: 14.139.160.195, 203.199.213.132 IPv6 address to authorize: --- Email contact: sriram@ae.iitm.ac.in Mirroring AltArch: no