This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 447788 - yum gives up too easily when it gets a 503 from RHN
yum gives up too easily when it gets a 503 from RHN
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: packaging-team-maint
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-21 15:36 EDT by Frank Ch. Eigler
Modified: 2013-12-18 10:32 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-18 10:32:08 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)

  None (edit)
Description Frank Ch. Eigler 2008-05-21 15:36:36 EDT
During busy times, rhn (or other repos) can return http 503 codes.
Yum appears to respond by giving up right away, aborting the whole
update process.  It would be better if youm were willing to retry
(with some backoff and some iteration limits), so that the update
is more likely to succeed even during RHN busy times.

yum-3.2.8-7.el5
yum-rhn-plugin-0.5.3-1.el5
Comment 1 James Antill 2008-05-21 15:59:14 EDT
 Does RHN respond with a Retry-After header? If not it seems like it's doing the
right thing.
Comment 2 Frank Ch. Eigler 2008-05-21 16:20:03 EDT
James, whom are you asking about retry-after?  I don't know whether rhn sends it
or not.  Even if it doesn't, the yum/rhn user experience may dictate that this
other code pretend otherwise.
Comment 3 Mike McLean 2012-06-08 12:49:34 EDT
Old issue, but this still seems to be the case. This doesn't seem limited to RHN. I'm seeing it in koji when the file server gets overburdened.

I have a test setup that throws random 503s with a Retry-After of 15. Yum chokes on the first one every time.

Looking at the code, I notice:
1) yum passes its retries setting to urlgrabber, but yum's callback handler effectively nullifies the urlgrabber retry mechanism by raising an exception
2) neither yum nor urlgrabber seem to distinguish 503s or look for a Retry-After header. urlgrabber lumps all HTTP errors under its errno=14
3) even if yum didn't block urlgrabber retries, errno=14 is not on the default retry list. yum could add it, but that would retry on all sorts of errors
Comment 4 RHEL Product and Program Management 2013-05-01 02:43:28 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 5 Zdeněk Pavlas 2013-12-18 10:32:08 EST
It's exactly as described in comment #3.  Needs fixing in yum, by backporting commit bfb49e7deab1394ff2c799ce345f69bf0a9583bd and few others, but since upstream has probably diverged quite a lot, the effort/gain seems rather low.

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