Bug 974946

Summary: Yum likes to hang without any output what it's doing and without reacting to CTRL+C
Product: [Fedora] Fedora Reporter: Jonas Thiem <jonas>
Component: yumAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: admiller, ffesti, firas.alkafri, jonas, jzeleny, lsof, opensource, packaging-team-maint, tla
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 15:36:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jonas Thiem 2013-06-17 08:34:05 UTC
Description of problem:
Yum often likes to hang without any output about what it's doing for a simple search task, and it doesn't react to CTRL+C when doing that.

While I believe it has good reason to do this sometimes (internet connection being slow or some other cause), the lack of information about what it is trying to do right now (most likely download some repo info) and the lack of any reaction to CTRL+C is very annoying.

[root@jth jonas]# yum search hamster
Loaded plugins: langpacks, refresh-packagekit

Not very fun! It likes to hang for a minute before reacting sometimes (rare but happens). Also, when using kill -9, the yum/rpm db is dead (understandably).

Version-Release number of selected component (if applicable):
bash-4.2$ yum --version
  Installed: rpm- at 2013-05-29 15:04
  Built    : Fedora Project at 2013-05-28 07:16
  Committed: Panu Matilainen <pmatilai@redhat.com> at 2013-05-28

  Installed: yum-3.4.3-91.fc19.noarch at 2013-05-29 15:05
  Built    : Fedora Project at 2013-05-13 15:30
  Committed: Zdenek Pavlas <zpavlas@redhat.com> at 2013-05-13

How reproducible:
Often (internet probably needs to be slow)

Steps to Reproduce:
1. Yum search
2. Watch it take forever
3. Use CTRL+C and see no response

Actual results:
CTRL+C doesn't do anything, there is no information given at all to what yum is doing right now and how long it will take, and this often takes up to one minute until yum is finally reacting to CTRL+C

Expected results:
Before the lengthy hanging task is carried out (whatever it is), I expect a notice what yum is doing (not even that it might take long if that's not normally the case, but just that it's doing SOMETHING). Also, yum should react to CTRL+C at least in a time span of like 5 seconds. Hanging for a minute after a CTRL+C when I clearly want to abort is not fun.

Additional info:

Comment 1 Zdeněk Pavlas 2013-06-17 12:16:36 UTC
Usually, this is caused by a dead mirror. Yum tries to connect() to an IP that does not respond at all.  You might want to try setting "timeout" in yum.conf to a smaller value than the 30s default.

But Yum might be also busy doing something else.  You run "yun search" as user- it might be just copying or unpacking metadata from the root cache.

If it's a network-related problem, please try running Yum with URLGRABBER_DEBUG=INFO and it will print few lines before each connection, so we can see where it blocks... eg:

$ sudo URLGRABBER_DEBUG=INFO yum update

Comment 2 Till Maas 2013-08-04 08:51:48 UTC
I noticed this behaviour when yum tried to download a pkgtags file or similar and rejected it because of a bad checksum from several mirrors. I then wanted to abort yum with CTRL-C  (to be able to run yum clean) and it just made yum hang.

Comment 3 Fedora End Of Life 2015-01-09 18:27:18 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Fedora End Of Life 2015-02-17 15:36:32 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 5 Need Real Name 2015-02-17 18:05:39 UTC
Ctrl-C is a pain point for yum. This really needs to be fixed. Could someone change this to F21?

Comment 6 Jan Zeleny 2015-02-18 07:01:41 UTC
(In reply to Need Real Name from comment #5)
> Ctrl-C is a pain point for yum. This really needs to be fixed. Could someone
> change this to F21?

I am sorry but since yum is going to be obsoleted with the release of F22 (it has been in maintenance mode for some time), it is highly unlikely that this bug will be fixed. If it wasn't for the EOL, this bug would be closed as WONTFIX.

Comment 7 Jonas Thiem 2016-08-22 11:47:28 UTC
This was initially reproduced years ago on hardware I no longer have, and might also have been related to HDD failure (for me personally). Also there's dnf now -> I hope it's ok if I clear the needinfo request involving me