Bug 590984

Summary: yumBackend.py takes 100% of the cpu forever(?)
Product: [Fedora] Fedora Reporter: Aner Gusic <aner.gusic>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: ffesti, james.antill, jonathan, maxamillion, pmatilai, richard, smparrish, tla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-19 12:54:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Aner Gusic 2010-05-11 07:18:34 UTC
Description of problem:
Sometimes, yumBackend.py fails in a way that it takes 90-100% of the cpu and never seems to exit.

Version-Release number of selected component (if applicable):
yum-utils-1.1.26-1.fc12.noarch
yum-3.2.27-2.fc12.noarch
yum-presto-0.6.2-1.fc12.noarch
anaconda-yum-plugins-1.0-5.fc12.noarch
yum-metadata-parser-1.1.2-14.fc12.i686
PackageKit-yum-plugin-0.5.7-2.fc12.i686
PackageKit-yum-0.5.7-2.fc12.i686


How reproducible:
Don't turn of your laptop for 2-4 days and this will happen.

 
Actual results:
yumBackend.py takes all the cpu and never exits.

Expected results:
yumBackend.py runs minutes not hours.

Additional info:
Could this bug be triggered by being behind a firewall? "yum update/install" works however. This is the config line in the yum.conf:
proxy=http://192.168.8.2:80

Comment 1 seth vidal 2010-05-11 14:24:13 UTC
I'm pretty sure this is the metadata reget bug.



download this yum
http://koji.fedoraproject.org/koji/buildinfo?buildID=166139

and see if it goes away.

Comment 2 Aner Gusic 2010-05-11 14:47:08 UTC
Thanks, updating as we speak. Will get back in a couple of days.

Comment 3 Aner Gusic 2010-05-19 09:46:46 UTC
The bug has not occured since I updated yum.  I suggest we close the bug, I'll make a new comment should the problem reoccur.

Thanks for the help