Bug 589316 - Config option history_record=0 is being ignored
Config option history_record=0 is being ignored
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-05 16:10 EDT by Bill Crawford
Modified: 2014-01-21 18:14 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-24 17:13:58 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)

  None (edit)
Description Bill Crawford 2010-05-05 16:10:40 EDT
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 16:41:08 EDT
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 17:05:40 EDT
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 17:08:02 EDT
... but I'll reinstall.
Comment 4 James Antill 2010-05-05 17:31:26 EDT
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 :).

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