Hi, Tru After that, we still sometimes hit centosa3 by rsync to msync.centos.org::CentOS-incdvd with the following command: rsync -avzH --delete-after --exclude=".~tmp~/" msync.centos.org::CentOS-incdvd /ftp/Linux/centos Since I have created and been running a very simple script to kill rsync when we hit centosa3, now our contents at ftp.riken.jp seems to be keeping always new one. Or did the lagging contents (Thu Apr 9 08:40:01 UTC 2009) problem of centosa3 fixed already ? Please let us know. Thanks. ============================================================== Thu May 21 15:10:01 UTC 2009 msync.CentOS.org rsync service (centosa3) --------------------------------------- This service is intended for the sole use of the CentOS worldwide mirror network to synchronize mirrors. Unless you are running or intending to run a listed public CentOS mirror use a mirror listed at http://www.CentOS.org/modules/tinycontent/index.php?id=13 If you intend to populate a mirror for public use please read the notes at :- http://www.CentOS.org/modules/tinycontent/index.php?id=15 If you do use this service then it is implied that you are providing a mirror for public use and giving us authority to publicise such mirror. receiving file list ... ######################################################### Thu May 21 15:11:01 UTC 2009 Upss! We hit centosa3. Rsync will be killed and restarted ######################################################### ============================================================ Thu May 21 15:11:02 UTC 2009 msync.CentOS.org rsync service (centosa3) --------------------------------------- : receiving file list ... ######################################################### Thu May 21 15:12:01 UTC 2009 Upss! We hit centosa3. Rsync will be killed and restarted ######################################################### ============================================================ Thu May 21 15:12:01 UTC 2009 msync.CentOS.org rsync service (centosa3) --------------------------------------- : receiving file list ... ######################################################### Thu May 21 15:13:01 UTC 2009 Upss! We hit centosa3. Rsync will be killed and restatted ######################################################### ============================================================ Thu May 21 15:13:01 UTC 2009 msync.CentOS.org rsync service (centosb3) --------------------------------------- : receiving file list ... done ./ deleting .rsync.log Regards, Takashi Ichihara 09.5.20 11:25 AM, Takashi Ichihara wrote, > Hi Tru > > Thanks. In the last rsync log in ftp.riken.jp, unfortunately we hit > centosa3 again!. > As a result, our contents of CentOS became obsolute. I killed it and > restarted > new rsync. (Maybe I will create a simple script to kill rsync when we > hit centosa3 ...) > > Tue May 19 17:03:01 UTC 2009 > > msync.CentOS.org rsync service (centosa3) > --------------------------------------- > > This service is intended for the sole use of the CentOS worldwide mirror > network > to synchronize mirrors. > > Unless you are running or intending to run a listed public CentOS mirror > use a mirror listed at > http://www.CentOS.org/modules/tinycontent/index.php?id=13 > > If you intend to populate a mirror for public use please read the > notes at :- http://www.CentOS.org/modules/tinycontent/index.php?id=15 > > If you do use this service then it is implied that you are providing a > mirror for public use and giving us authority to publicise such mirror. > > receiving incremental file list > deleting .rsync.log > ./ > deleting 2.1/updates/headers/tzdata-0-2009f-1.el2_1.noarch.hdr > deleting > 2.1/updates/headers/seamonkey-nss-devel-0-1.0.9-0.33.el2.c2.1.i386.hdr > deleting 2.1/updates/headers/seamonkey-nss-0-1.0.9-0.33.el2.c2.1.i386.hdr > deleting > 2.1/updates/headers/seamonkey-nspr-devel-0-1.0.9-0.33.el2.c2.1.i386.hdr > deleting 2.1/updates/headers/seamonkey-nspr-0-1.0.9-0.33.el2.c2.1.i386.hdr > : > 4.7/apt/i386/base/ > deleting > 4.7/centosplus/x86_64/headers/kernel-xenU-devel-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-xenU-devel-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-xenU-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-xenU-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-smp-devel-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-smp-devel-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-smp-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-smp-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-largesmp-devel-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-largesmp-devel-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-largesmp-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-largesmp-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-doc-0-2.6.9-78.0.22.plus.c4.noarch.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-doc-0-2.6.9-78.0.17.plus.c4.noarch.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-devel-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-devel-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-0-2.6.9-78.0.22.plus.c4.x86_64.hdr > deleting > 4.7/centosplus/x86_64/headers/kernel-0-2.6.9-78.0.17.plus.c4.x86_64.hdr > 4.7/apt/i386/base/pkglist.centosplus.bz2 > : > > 09.05.20 4:38 AM (UT+9), Tru Huynh wrote, > >> On Wed, May 20, 2009 at 12:08:59AM +0900, Ichihara Takashi wrote: >> >> >>> Hi Tru >>> >>> The host centosa3 still remained at least untill Tue May 19 >>> 01:03:02 UTC 2009 and this host seems to be make problem. >>> >>> >> ... that's weird ... >> >> according to the logs of the pdns backend, I have: >> 124.217.252.175 <- centosa3.centos.org >> # 2009/04/06 removing A3 124.217.252.175 (9 days late delaying other mirrors) >> >> a3 being one of the pdns server, it might haven't caught the change and >> still serving the wrong entry. I am checking this now. >> >> Best regards, >> >> Tru >> >> > >