I don't believe this is a problem with ncftp itself (I'm running ncftp-3.0beta9-1), but rather with the ftp.redhat.com site. I have a script that uses ncftpls and ncftpget to grab the latest files from ftp.redhat.com/rawhide/i386/RedHat/RPMS. I have been using this script successfully for quite a while, but it failed today. I ran the script several times this morning, using two different ISPs (TCI@Home and SGI). With each ISP, my first run of the script accessed what appeared to be an up-to-date version of ftp.redhat.com/rawhide/i386/RedHat/RPMS, but when the script attempted to retrieve some of the files, ncftpget returned error 3 (transfer failed) on about half of the files The other half of the files were retrieved successfully. The transfer failures occurred in an alternating pattern -- if one transfer succeeded, the next one would fail, and the next one would succeed, etc. With each ISP that I tried, subsequent runs of my script after the first accessed what appeared to be an out-of-date version of ftp.redhat.com/rawhide/i386/RPMS. Most of the packages appeared in older versions; e.g. on the first run ncftpget picked up kernel-2.2.10-3, but on subsequent runs ncftpget picked up kernel-2.2.5-25. When I tried ncftp in interactive mode and did an ls, I saw the older versions. Perhaps there is some sort of route-flapping going on between multiple ftp.redhat.com servers, or a load balancing mechanism that is selecting between multiple servers that aren't in sync with each other? For completeness, here is the script: #!/bin/bash buildtime() { rpm -q --queryformat '%{BUILDTIME}' $* } rpmget() { echo -n "opening ftp://$1/: " files=$(ncftpls ftp://$1/); ret=$? if [ $ret -ne 0 ]; then echo ERROR ncftpls returned $ret return fi echo ok for file in $files; do echo -n "$file: " pkg=${file%-*-*} pkgver=${file%.*.rpm} if [ ${file##*.} != rpm ]; then echo skipping elif ! eval rpm -q $pkg &> /dev/null; then echo pkg not installed elif eval rpm -q $pkgver &> /dev/null; then echo pkg already installed elif [ -f ./$file -o -f ../krpm/$file -o -f ../orpm/$file ]; then echo already downloaded else oldfile= for f in ./$pkg-[0-9]* ../krpm/$pkg-[0-9]*; do fp=${f##*/};fp=${fp%-*-*} if [ -f $f -a $fp = $pkg ]; then oldfile=$f break fi done ncftpget ftp://$1/$file &> /dev/null; ret=$? if [ $ret -ne 0 ]; then echo ERROR ncftpget returned $ret elif ! eval rpm -K --nopgp $file &> /dev/null; then echo ERROR checksig failed rm -f $file elif [ $(buildtime -p $file) -lt $(buildtime $pkg) ]; then echo older version mv $file ../orpm else echo NEW if [ ${pkg%%-*} = kernel ]; then mv $file ../krpm fi if [ -f ./$oldfile ]; then mv $oldfile ../orpm; fi fi fi done } cd /1/pkg/rpm { rpmget ftp.falsehope.com/pub/Mesa/rh6.0 rpmget ftp.falsehope.com/pub/socks5 rpmget ftp.redhat.com/rawhide/i386/RedHat/RPMS rpmget ftp.redhat.com/rawhide/powertools/i386 rpmget ftp.redhat.com/redhat/updates/6.0/i386 } 2>&1 | tee /1/pkg/getrpm.log
There have been recent rearrangements of ftp.redhat.com. These problems should be fixed now.
This problem appears to me to be still unresolved. I am continuing to see the same behavior. I'm seeing two seemingly separate problems: - two competing versions of ftp.redhat.com/rawhide/i386/RedHat/RPMS. One version (call it A) seems to have the latest versions of everything except wmmon, which is at 1.0b2-3. The other version (call it B) seems to have out-of-date versions of most things, except wmmon which is at 1.0b2-4. I've been running my script repeatedly, and sometimes I get A; sometimes I get B. - My script invokes ncftpget repeatedly. Odd-numbered invocations (1, 3, 5...) fail with error 3 (transfer failed), and even-numbered invocations (2, 4, 6) succeed. I added a workaround to my script -- if ncftpget fails, the script just tries again. This works, but the underlying problem remains. This is a new problem; the last time I ran my script (about 2 weeks ago), using the same system configuration (including ncftp-3.0beta19-1) everything was fine. I tried fiddling with the ncftpget timeout and redial options, but didn't find a way to eliminate the failures. -Craig Dunwoody dunwoody
I'm not seeing this problem now, so I'll be optimistic and assume it's gone for good. I'd like to re-close this bug myself to save you the trouble, but if there's a way for me to do that I don't know what it is (possible bugzilla RFE?). Thanks very much for the quick response on these bug reports -- impressive!
ftp.redhat.com is aliased to two separate machines. Hence, if one has the updated files and one doesn't (this could happen if you're trying to download while the machines are syncing, for example), weird things can happen. I'm not sure there's much we can do about this, though.