Bug 589316

Summary: Config option history_record=0 is being ignored
Product: [Fedora] Fedora Reporter: Bill Crawford <billcrawford1970>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: ffesti, james.antill, maxamillion, mschmidt, pmatilai, tim.lauridsen
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: 2011-05-24 21:13:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bill Crawford 2010-05-05 20:10:40 UTC
Description of problem:
Updates taking too long. Notice that /var/lib/yum/history is being updated (and this is taking a lot of extra time during transaction processing). This is even though I set the history_record=0 option in /etc/yum.conf ...

Version-Release number of selected component (if applicable):
Both the previous version (I can't remember the release number) and the current update (3.2.27-4.fc13) are exhibiting this problem.

How reproducible:
Start an update. Wait ... and wait ... and wait.

Steps to Reproduce:
1. Run "yum --noplugins --enablerepo local-updates-testing update"
2. Watch as it solves the dependencies, enter "y" and return.
3. Watch as it then takes over ten minutes to run the transaction (for seven packages).

Actual results:
Ten minute delay.

Expected results:
No ten minute delay.

Additional info:
I will, eventually, be replacing this PC with one that will cope with yum history and yum's other aspirations. However for the time being, I would like it to do what I ask it to. Being able to disable this "yumdb" (which is pretty pointless when most updates are being installed from updates-testing but end up in the development/13 repository, so the install source is meaningless) would be nice too. Please?

Comment 1 seth vidal 2010-05-05 20:41:08 UTC
10 minutes??

Can you please provide the output from any transaction like this of

yum -d 3 whateveryourunhere

thanks

Comment 2 Bill Crawford 2010-05-05 21:05:40 UTC
The ten minutes (actually 11) is because it's a rather old machine with just enough memory to run a desktop, and it wasn't the length of time that bothered me particularly, just that I thought I'd disabled the feature. The debug output shows nothing relating to the creation / update of the history database, I actually had to add some to figure out what was going on when I first ran into this problem - which was why I tried to turn it off in the config. I've also just edited the history out of my installed copy of yum so it wouldn't help much anyway ;o)

Comment 3 Bill Crawford 2010-05-05 21:08:02 UTC
... but I'll reinstall.

Comment 4 James Antill 2010-05-05 21:31:26 UTC
The feature is disabled, it's just that the feature only controls recording history transactions ... we still create the dir. and setup the history .sqlite file. This is because it's much easier to have a readable, but empty, history file than to have none at all.

Likely the time spent, is the "yum check" operations which are automatically done when we don't have a previous history file to test that nothing has changed since. I've just submitted a patch upstream to turn those off. To test that theory you can run:

yum check dependencies
yum check duplicates

...if those combined are your missing time, then that'll explain it. If you need to remove it quick I can tell you which lines to delete in __init__.py ... or just wait for 3.2.28 (or get a newer machine :).