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.

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.

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)

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.

Created attachment 271321 [details]
Console log running yum and yumex

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.

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.

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.

Yes, today its doing it again for me too. Yum at the command works fine.

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.

*** Bug 287371 has been marked as a duplicate of this bug. ***

This is fixed in yum-updatesd git.