hey guys,
Quick heads up - CentOS 4.3 is going to open upto rsync during the course of today, you might want to make sure that drive space issues, network issues etc are all sorted out before then.
4.3 is only going to be available via msync.centos.org - and NOT mirror.centos.org, so make sure you rsync's are pointing to the correct location - in some cases, it might be better to use another rsync mirror close to you, rather than the centos.org network, to ensure faster prorogation.
Either Johnny or I will post to the mailing list, before the /4/ symlink moves over from /4.2 tree to the /4.3 tree ( and therefore the user end traffic ).
Hi Karanbir,
How much extra diskspace is needed, the 4.2 is 30G, should one have at least 30G free diskspace,
best regards Lars
On Fri, 2006-03-17 at 13:31 +0100, Lars Bruno Hansen wrote:
hey guys,
Quick heads up - CentOS 4.3 is going to open upto rsync during the course of today, you might want to make sure that drive space issues, network issues etc are all sorted out before then.
4.3 is only going to be available via msync.centos.org - and NOT mirror.centos.org, so make sure you rsync's are pointing to the correct location - in some cases, it might be better to use another rsync mirror close to you, rather than the centos.org network, to ensure faster prorogation.
Either Johnny or I will post to the mailing list, before the /4/ symlink moves over from /4.2 tree to the /4.3 tree ( and therefore the user end traffic ).
Hi Karanbir,
How much extra diskspace is needed, the 4.2 is 30G, should one have at least 30G free diskspace,
That is about right for this one too ... but after all arches are released and all the external mirror syncs are done, we will move the 4.2 tree into the vault ...
Then the size should shrink back down to be similar to now for the overall mirror.
Just as an aside: This is an excellent time to implement a lock file system. As it says on the mirror site,
"We highly recommend the use of lock files in your cron script so that you don't spawn multiple connections which is hard on our servers and on your mirror. If you don't know how to do this, please ask the list."
Lock files are a good thing (tm). I'm sure there's a better way to do it, but I'm doing the following:
if [ -f /some/path/lockfile ] then exit fi touch /some/path/lockfile rsync -blah -blah us-msync.centos.org::CentOS /my/mirror rm -f /some/path/lockfile
~Will Virginia Tech CS dept techstaff
Johnny Hughes wrote:
On Fri, 2006-03-17 at 13:31 +0100, Lars Bruno Hansen wrote:
hey guys,
Quick heads up - CentOS 4.3 is going to open upto rsync during the course of today, you might want to make sure that drive space issues, network issues etc are all sorted out before then.
4.3 is only going to be available via msync.centos.org - and NOT mirror.centos.org, so make sure you rsync's are pointing to the correct location - in some cases, it might be better to use another rsync mirror close to you, rather than the centos.org network, to ensure faster prorogation.
Either Johnny or I will post to the mailing list, before the /4/ symlink moves over from /4.2 tree to the /4.3 tree ( and therefore the user end traffic ).
Hi Karanbir,
How much extra diskspace is needed, the 4.2 is 30G, should one have at least 30G free diskspace,
That is about right for this one too ... but after all arches are released and all the external mirror syncs are done, we will move the 4.2 tree into the vault ...
Then the size should shrink back down to be similar to now for the overall mirror.
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
William Dunn wrote:
Lock files are a good thing (tm). I'm sure there's a better way to do it, but I'm doing the following:
if [ -f /some/path/lockfile ] then exit
The downside of lockfiles is that if your script crashes they stay behind and keep blocking until you realise it and remove them manually. A somewhat better way to do this could be to look for the process. Something like
lock=`/bin/ps auxwww |/bin/grep rsync |/bin/grep msync.centos.org` if [ -n "$lock" ] then exit fi
Z
On Sat, Mar 18, 2006 at 12:44:55AM -0500, Zenon Panoussis wrote:
if [ -f /some/path/lockfile ] then exit
The downside of lockfiles is that if your script crashes they stay behind and keep blocking until you realise it and remove them manually. A somewhat better way to do this could be to
Not necessarily. Do something like this:
trap "rmdir ${LOCKFILE}" EXIT TERM INT QUIT
and it'll get removed no matter the reason your script quit.
It's better to use directories than regular files for lockfiles, because you can use mkdir to both test for existence and create the lock if it isn't there already.
It'd also be better to trap each exit individually and log a separate message for each....
On Sat, Mar 18, 2006 at 12:44:55AM -0500, Zenon Panoussis wrote:
The downside of lockfiles is that if your script crashes they stay behind and keep blocking until you realise it and remove them manually. A somewhat better way to do this could be to look for the process. Something like
Actually, a lock-file should have the PID in it, and checking the lock file would involve checking to see if the PID exists, and if not you nuke the lockfile.
That said, I had a rsync hang up for 2 weeks once, and so now I have a script from cron that once every day or two kills all the running rsyncs and removes all the lock files. Since then, I haven't had any issues with stuck mirrors.
Thanks, Sean
or you can use simba ;) (http://simba.packages.ro)
On Fri, Mar 17, 2006 at 09:52:18AM -0500, William Dunn wrote:
Just as an aside: This is an excellent time to implement a lock file system. As it says on the mirror site,
"We highly recommend the use of lock files in your cron script so that you don't spawn multiple connections which is hard on our servers and on your mirror. If you don't know how to do this, please ask the list."
Lock files are a good thing (tm). I'm sure there's a better way to do it, but I'm doing the following:
if [ -f /some/path/lockfile ] then exit fi touch /some/path/lockfile rsync -blah -blah us-msync.centos.org::CentOS /my/mirror rm -f /some/path/lockfile
~Will Virginia Tech CS dept techstaff
-
Johnny Hughes -
Lars Bruno Hansen -
Matthew Miller -
Sean Reifschneider -
Subredu Manuel -
William Dunn -
Zenon Panoussis