Bug 186195 - wget fails to download on second try, where it would succeed on first try
wget fails to download on second try, where it would succeed on first try
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: wget (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-22 00:15 EST by Alexei Podtelezhnikov
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-08 05:32:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fix (325 bytes, patch)
2006-12-03 18:02 EST, Tomas Heinrich
no flags Details | Diff

  None (edit)
Description Alexei Podtelezhnikov 2006-03-22 00:15:27 EST
Description of problem:  
  
Wget fails to download on second and following tries, but succeeds on first.  
I am sure that file exists in fedora update directory, but wget is to busy 
retrying and fails to see it when it finally succeeds connecting. 
Here is a _typical_ scenario with downloading updates for FC4:  
  
 [root@localhost updates]# wget -N  
'ftp://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/bind*9.3.1-18.FC4.i386.rpm'  
--00:06:37--   
ftp://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/bind*9.3.1-18.FC4.i386.rpm  
           => `.listing'  
Resolving download.fedora.redhat.com... 209.132.176.20, 209.132.176.220,  
209.132.176.221, ...  
Connecting to download.fedora.redhat.com|209.132.176.20|:21... connected.  
Logging in as anonymous ...  
Error in server greeting.  
Retrying.  
  
--00:06:38--   
ftp://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/bind*9.3.1-18.FC4.i386.rpm  
  (try: 2) => `.listing'  
Connecting to download.fedora.redhat.com|209.132.176.20|:21... connected.  
Logging in as anonymous ... Logged in!  
==> SYST ... done.    ==> PWD ... done.  
==> TYPE I ... done.  ==> CWD not required.  
==> PASV ... done.    ==> LIST ... done.  
  
    [ <=>                                 ] 126           --.--K/s  
  
00:06:39 (7.07 MB/s) - `.listing' saved [126]  
  
Removed `.listing'.  
No matches on pattern `bind*9.3.1-18.FC4.i386.rpm'.  
  
Let's do it again:  
  
  
Version-Release number of selected component (if applicable):  
  
  
How reproducible:  
100% with fedora site  
  
Steps to Reproduce:  
1. now is a good time because the fedora site is busy with FC5  
2. try to download something, it's important to fail on first wget try  
3. second, or later try fails me with no match found 
    
Actual results:  
  
  
Expected results:  
  
  
Additional info:
Comment 1 Jeff Groves 2006-04-27 15:35:17 EDT
Additionally, I have had to update my scripts that use wget to add the "-4"
parameter to get wget to work properly again.

The -4 parameter forces wget to use IPv4.

I'm thinking this is a glibc-2.3.6-3 problem that is causing side-effects in
wget.. and possibly other glibc dependent utilities.

My $0.02

Jeff G.
Comment 2 Tomas Heinrich 2006-12-03 18:00:46 EST
as you can see from your wget output, it refuses to do cwd;
  "... ==> CWD not required. ..."
the file isn't found because you are left in the root directory.

another problem caused by this bug is that when no errors occur,
wget always cwd, even if unnecessary.

it is easily triggered with the .listing bug:
  $touch .listing
  $wget "ftp://kernel.org/pub/REA*ME"
  wget refuses to overwrite .listing and reconnects; failing cwd
Comment 3 Tomas Heinrich 2006-12-03 18:02:35 EST
Created attachment 142692 [details]
fix
Comment 4 Alexei Podtelezhnikov 2006-12-04 13:03:14 EST
Beautiful fix for a bug that still exists in FC6.
Comment 5 Karsten Hopp 2006-12-08 05:32:18 EST
I've added this patch to the Rawhide package
Comment 6 Fedora Update System 2007-01-10 11:05:59 EST
wget-1.10.2-8.fc6.1 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 7 Steve Malenfant 2007-01-22 11:08:03 EST
I think wget is broken now, since I updated to 1.10.2-3.3.fc5 (and the fc6
version) the recursive feature doesn't work anymore...

[root@VTS-MOINEAU cron.daily]# wget -A.ts,.mpg,.pcap,.bin -nd -P /video/ -r -N
-l inf ftp://x.x.x./Transport/TestPlan/
--11:03:33--  ftp://x.x.x.x/Transport/TestPlan/
           => `/video/.listing'
Resolving x.x.x.x... 10.17.224.40
Connecting to x.x.x.x|10.17.224.40|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /Transport/TestPlan ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                                                      ]
777         --.-K/s   in 0s

11:03:33 (1.78 MB/s) - `/video/.listing' saved [777]

Removed `/video/.listing'.
Wrote HTML-ized index to `/video/index.html' [1608].

I updated on January 17th, before that everything worked fine.  Do I have a
problem with my command line?

This doesn't work either :
wget -nd -r ftp://x.x.x.x/Transport/TestPlan/
Comment 8 Alexei Podtelezhnikov 2007-01-24 10:13:51 EST
(In reply to comment #7)

How is this related to this particular bug report?
File your own bug report. ;) 
Comment 9 Richard Dale 2007-05-30 03:06:42 EDT
I recently had a similar issue as that from comment #7.  Here's how to solve it:

add a trailing wildcard to the line... ie:
wget -nd -r ftp://x.x.x.x/Transport/TestPlan/*


Note You need to log in before you can comment on or make changes to this bug.