Bug 859035 - yum tries to download from non-functional mirror
Summary: yum tries to download from non-functional mirror
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-20 12:30 UTC by Dan Horák
Modified: 2014-01-21 23:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-20 15:46:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dan Horák 2012-09-20 12:30:15 UTC
yum tries to download from non-functional mirror, it detect a timeout, but tries the same mirror again for every package

...
(46/89): openssl-libs-1.0.1c-7.fc18.s390x.rpm                                                                                                  |    0 B  00:00:30     
http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/o/openssl-libs-1.0.1c-7.fc18.s390x.rpm: [Errno 12] Timeout on http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/o/openssl-libs-1.0.1c-7.fc18.s390x.rpm: (28, '')
Trying other mirror.
(47/89): pam-1.1.6-1.fc18.s390x.rpm                                                                                                            |    0 B  00:00:30     
http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/pam-1.1.6-1.fc18.s390x.rpm: [Errno 12] Timeout on http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/pam-1.1.6-1.fc18.s390x.rpm: (28, '')
Trying other mirror.
(48/89): pcre-8.31-2.fc18.s390x.rpm                                                                                                            |    0 B  00:00:30     
http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/pcre-8.31-2.fc18.s390x.rpm: [Errno 12] Timeout on http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/pcre-8.31-2.fc18.s390x.rpm: (28, '')
Trying other mirror.
(49/89): perl-5.16.1-229.fc18.s390x.rpm                                                                                                        |    0 B  00:00:30     
http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/perl-5.16.1-229.fc18.s390x.rpm: [Errno 12] Timeout on http://download-i2.fedoraproject.org/pub/fedora-secondary/development/18/s390x/os/Packages/p/perl-5.16.1-229.fc18.s390x.rpm: (28, '')
Trying other mirror.
...


Version-Release number of selected component (if applicable):
yum-3.4.3-42.fc18.noarch


Notes:
There seems to be a problem with accessing the http://download-i2.fedoraproject.org host from inside RH, but previous versions of yum detected the failed mirror in the first down load and then simply didn't use it.

Comment 1 Zdeněk Pavlas 2012-09-20 14:38:56 UTC
This is caused by the "private" mirror flag..  DL failures increment the mirror's failure counter, halving speed estimate each time.  Normally, Yum would avoid this mirror after few failures, but the "private" flag overrides speed estimate, and there's just one private mirror, so urlgrabber still considers this one the best..

But for any given request, when the "private" mirror fails, it should be masked, and other (non-private) mirrors should be tried in turn.. is this the case?  The log suggests that ONLY one mirror is ever tried..

Re the bug: We want to prefer private mirrors, but probably only when there are no recent failures.  If the mirror failed last time, ignore the private flag, and use ordinary speed estimation.. do you think that could work?

Comment 2 Dan Horák 2012-09-20 14:53:00 UTC
(In reply to comment #1)
> This is caused by the "private" mirror flag..  DL failures increment the
> mirror's failure counter, halving speed estimate each time.  Normally, Yum
> would avoid this mirror after few failures, but the "private" flag overrides
> speed estimate, and there's just one private mirror, so urlgrabber still
> considers this one the best..
> 
> But for any given request, when the "private" mirror fails, it should be
> masked, and other (non-private) mirrors should be tried in turn.. is this
> the case?  The log suggests that ONLY one mirror is ever tried..

Yeah, I have noticed later that the files are not actually downloaded and only zero sized "files" are stored in the yum cache. What's interesting is that metadata from a non-private mirror are downloaded, but the packages are not. I will check if the next mirror is broken.

> Re the bug: We want to prefer private mirrors, but probably only when there
> are no recent failures.  If the mirror failed last time, ignore the private
> flag, and use ordinary speed estimation.. do you think that could work?

I think it works so in F-16 (guests on the same s390 machine I was trying here) - when the first (private) mirror fails, then all subsequent downlads are switched to next mirror.

Comment 3 Fedora Update System 2012-09-27 10:57:02 UTC
python-urlgrabber-3.9.1-21.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-21.fc18

Comment 4 Fedora Update System 2012-09-28 00:14:12 UTC
Package python-urlgrabber-3.9.1-21.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-urlgrabber-3.9.1-21.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14928/python-urlgrabber-3.9.1-21.fc18
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2012-12-20 15:46:35 UTC
python-urlgrabber-3.9.1-21.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


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