Red Hat Bugzilla – Bug 189318
yum reliably triggers oom-killer
Last modified: 2014-01-21 17:53:53 EST
Description of problem:
Yum suddenly started triggering the oom-killer today.
Version-Release number of selected component (if applicable):
I tried sever versions on yum
from latest repo-yum as/of few days ago
& yum-2.6.0-1.src.rpm from FC5 sources
I tried a couple of kernels (stock FC4, x86_64)
Every time since just today.
Steps to Reproduce:
1. yum info yum (actually seems independent of args)
2. after 5 seconds-or so, starts using swap
3. after few-more secs starts oom-kill thrashing
4. system DOES respond to SysReq S/U/B recipe
<heh> shouldn't gobble all the world's memory
from cat cpuinfo..
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3500+
stepping : 0
cpu MHz : 2210.202
cache size : 512 KB
Normal memory stats:
total used free shared buffers cached
Mem: 1004 580 423 0 25 282
-/+ buffers/cache: 272 732
Swap: 972 0 972
Most recent yum updates
Apr 13 23:13:53 Updated: plone.x86_64 2.1.2-2.fc4
Apr 13 23:14:43 Updated: abiword.x86_64 1:2.4.4-2.fc4
Apr 14 19:42:47 Updated: gnochm.noarch 0.9.7-4.fc4
Most recent manual installs (reverse-chron):
why'd you install sqlite 3.3.3?
b/c that's what's causing the memory overrun.
Whoa! How did you pinpoint that? That seemed to be it. I did a rpm --oldpackage back
to sqlite-3.1.2-3 (from FC4) and yum works now.
To answer your question: I had some thought of upgrading python-sqlite2, and seemed to
<accidentally> grab the 126.96.36.199 version from FC5. Then when it griped about needing
sqlite3.3, I thought I would be safe installing the FC5 sqlite3.3 if I compiled it in
my environment -- guess that may have been an incorrect assumption <grin>.
So ... problem is resolved..
..but I still want to know how you knew?
My sincere respects!!
And warm thanks for the prompt feedback, too.
It's been reported before. Paul Nasrat discovered it. I just read it.