Red Hat Bugzilla – Bug 116474
yum hangs after producing some output
Last modified: 2014-01-21 17:49:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040207 Firefox/0.6 StumbleUpon/1.66
Description of problem:
Yum hangs, no matter what I try to do with it.
In particular, 'yum -d3 install yum' produces some output and then it
stops producing output. A tail of the output is given in the next
section of this report.
I have a broadband connection. Yum has been sitting there, producing
no output but using most of my CPU power, for over an hour. It is not
causing any disk accesses, nor is my cisco675 conector indicating
access to the outside world, so I assume it is hung.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run 'yum info' or 'yum list' or 'yum install yum' [probably others]
Actual Results: Best ver+arch installed for kernel is i686
Downloading needed headers
Disabling Keepalive support by user configuration
failover: baseURL =
failover: path = /headers/pango-0-1.3.2-3.i386.hdr
Expected Results: Installation.
I removed all the mirrors because I had worse results. (Trust me, I
spent hours trying to find workable mirrors.)
I'd like to use yum because it is reputed to be faster than up2date.
The latter is terribly slow, e.g. 1/2 hour to install a package, on my
I'm curious - how long does it hang? Does it hang forever? Could try
connecting to a different mirror? I've heard of someone else having
similar problems connecting to download.fedora.us before and I'd like
to remove some variables.
FWIW, I frequently get hangs while reading from socket
from download.fedora.redhat.com. Patient persistence,
or trying another mirror worksforme.
Created attachment 97933 [details]
yum configuration file
Seth Vidal asks how long it hangs. The answer is that I've left it
hanging for an hour or so before giving up. Would it help if I left
it overnight, to get another data point? It seems pretty clear that
I'll get the same results, since
(a) the hour I've waited is significantly longer than the 1/4-hour
time required to rebuild the RPM database [suggesting to me that there
is no yum-related computation of that scale]
(b) there are no noticable disk accesses [suggesting to me that the
calculation is not doing anything productive]
(c) there are no noticable file transfers over my broadband connection
[suggesting that the yum work is not limited by a large amount
In summary, the yum process takes nearly 100% of the CPU without, as I
said, printing anything even at the highest 'verbosity' level,
noticibly accessing the disk, or accessing the internet. And it uses
that CPU resource over a timescale longer than I would expect, based
on inferences from similar work.
I hope this helps. As I said, I could leave it running overnight, so
that I could post here again and report a larger number. But it would
seem to be more sensible for me to do other tests, and I'd be happy
to do so, if advised. In case it helps, I've attached my
/etc/yum.conf file. Maybe I'm just being wrong-headed about it. (I
am a yum newbie, but I'm hopeful!)
1. why did you disable keepalive?
2. setting retries to 0 makes it try forever for a failure.
I'm betting your retries statement is the source of the problem.
I've experienced such hangs also, and am doing right now. Its been
going for several hours, but there is no cpu usage, contrary to what
Dan is finding. I have experienced such results with all yum versions
I have had. Previously it has been due to rpm hanging, but with fc2
dev versions there has been no rpm instance running. The
configuration is default appart from some mirrors of fedora.us and my
own mirror of the redhat server. kill -9 <process_id> has no effect
on the process. Current is latest as of this post. Place of freeze
is just after all the list of repositories has been printed.
The 1st problem appears to be resolved, use mis-configuration.
#2 smells like a stale rpmdb lock because of no cpu usage.
rm -f /var/lib/rpm/__db*
to remove stale locks.
Please reopen if stale locks was not the problem.