Bug 400841 - excessive bandwidth use
excessive bandwidth use
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum-updatesd (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
: 287371 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 07:18 EST by David Woodhouse
Modified: 2008-05-28 16:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-28 16:29:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console log running yum and yumex (1.59 KB, text/plain)
2007-11-28 08:31 EST, Marek Zukal
no flags Details

  None (edit)
Description David Woodhouse 2007-11-27 07:18:08 EST
I got a text message this morning from my ISP, indicating that I've exceeded my
peak-hours bandwidth usage limit for this month.

Investigation seems to show that a bunch of machines are running yum-updatesd,
and are frequently downloading megabytes of data from remote services. It seems
to be doing this over and over again.
Comment 1 Jeremy Katz 2007-11-27 09:25:05 EST
yum-updatesd checks for updates and will do it based on the frequency in
/etc/yum/yum-updatesd.conf or on demand (eg, from puplet).  The check for
updates requires downloading the metadata and if you're using out of sync
mirrors, then it's going to have to pull multiple times.
Comment 2 Marek Zukal 2007-11-27 09:36:08 EST
I think the problem is not in frequency of checking updates. When it is checking
for updates and the checksum of package list is bad, it tries to download the
list from other servers indefinitely. Tragedy happens when checksum of all the
servers is bad. It happend this morning about 5 hours ago (10:00 GMT+1). I have
seen it on my F7 some time before. Today freshly installed F8 machine downloaded
about 200MB of data in cca one hour. If it is a only configuration issue, it
should be configured reasonably by default.
Comment 3 David Bentley 2007-11-27 18:38:35 EST
I have seen this behavior in rawhide before when a lot of mirrors were out of
sync but today was the first time with F8.

The usual fix is turn yum-updatesd off and re-boot then run yum update.
when this was done yum had no problems finding updates which all installed OK so
I turned yum-updatesd back on and re-booted and on loging into am x session you
get perpetual network activity which stops when you stop yum-updatesd (kill it).

If you then run yum update in a terminal it just comes back saying no updates.

If you then use the gui updater the bar reaches 100% and the network activiry
continues indefinatly again until you cancel it.

If you the run yum update in a terminal again it just comes back saying no
updates available again

I fixed this in the past when this problem occured in rawhide by stoping yum
using the mirror list but this is not desirable.

since the gui updater and yum-updatesd exibit the problem but yum doesn't the
problem possibly lies elsewhere (PIRUT perhaps)
Comment 4 Bruce Brackbill 2007-11-28 01:39:34 EST
I am experiencing this also ( F8 ).  Very disconcerting.

It's like yum-updatesd/pup manages to tie itself in to a knot that it can't get
out of, continuing to download huge amounts of data taking up all my bandwidth
never completing its task. On the other hand, yum from the terminal works fine.

Comment 5 Marek Zukal 2007-11-28 08:31:39 EST
Created attachment 271321 [details]
Console log running yum and yumex
Comment 6 Michael Young 2007-11-28 16:12:06 EST
I think the reason why this is happening is that the comps-f8.xml file on the
master updates server is different from the one on most of the mirrors but it
has the same timestamp and size which is fooling the mirrors into thinking they
have the right file (most synchronizations just check the size and date). Hence
this process just runs through he multitude of mirrors with the wrong files then
loops or starts again after 10 minutes.
But an automated precess like this should have a bandwidth limit, or give up
after  maybe 5 wrong answers.
Comment 7 Marek Zukal 2007-11-29 01:56:19 EST
Eventually it gives up. Puplet notices that it cannot accept updates but I
cannot tell if it is because it hits some limit of unsuccessful attempts or it
just does not know any other mirror server.
Comment 8 Ron Yorston 2008-01-12 06:31:04 EST
It's doing it again:  downloading comps-f8.xml over and over and over and over
again.  The process should cope gracefully with mirror problems.  Goodness
knows, they happen often enough.  Just sitting there eating bandwidth ad
infinitum is really unfriendly, bordering on hostile.  Bandwidth costs money.

I've turned yum-updatesd off until it learns some manners.
Comment 9 Bruce Brackbill 2008-01-12 14:46:03 EST
Yes, today its doing it again for me too. Yum at the command works fine.
Comment 10 Marek Zukal 2008-02-07 06:26:03 EST
11:17:58 UTC - the same behavior. Yumex and yum-updatesd waste bandwidth by
endless downloading metadata from various mirrors. yum runs fine and shows some
updates. I guess mirrors are being synchronized right now.
Comment 11 Jeremy Katz 2008-05-28 15:05:10 EDT
*** Bug 287371 has been marked as a duplicate of this bug. ***
Comment 12 Jeremy Katz 2008-05-28 16:29:57 EDT
This is fixed in yum-updatesd git.

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