This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 240138 - ctrl-c/SIGINT yum vs. rpm, checkSignals() in rpm kills yum
ctrl-c/SIGINT yum vs. rpm, checkSignals() in rpm kills yum
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Antill
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-15 09:54 EDT by Jim Perrin
Modified: 2009-01-20 16:44 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:44:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jim Perrin 2007-05-15 09:54:32 EDT
Description of problem:
when yum catches a single ctrl (for example to switch to a faster mirror for
downloading) it finishes the download, but does not install the package. Yum
should die completely on two ctrl-c's, but if the application continues, then it
should finish all steps. 

Version-Release number of selected component (if applicable):
yum-3.0.1-5.el5.noarch

How reproducible:
always

Steps to Reproduce:
1. install package from slow mirror
2. hit ctrl-c once to change mirrors
3. watch yum fetch package, but not install it. 
  
Actual results:
yum fetches package but does not install.

Expected results:
yum should switch to new mirror, and continue initial action of installing package. 

Additional info:
This behavior also occurs in every version of yum in fedora up to the -testing.
I've not tested with the yum in the fc development tree.
Comment 1 Doncho N. Gunchev 2007-06-01 13:01:35 EDT
  I was using the development tree till yesterday, the behavior is the same.
Maybe Ctrl-\ (back slash) should kill yum instantly if ctrl-C will be used to
switch mirrors (quite useful feature, I use it often and when it finishes
downloading I run the command again - the packages are already downloaded).
Comment 2 Jim Perrin 2007-06-01 13:06:51 EDT
Well, the code states that 2 quick ctrl-c's should kill yum, and it does. I
would keep ctrl-c as a kill, as this is standard, but either allow yum to finish
installing if it doesn't die, or use another key combination to switch mirrors. 
Comment 3 Jeremy Katz 2007-09-13 14:05:40 EDT
This should be better as of yum 3.2.5 if you have rpm 4.4.2.1 or later
Comment 4 Jim Perrin 2007-09-13 15:50:59 EDT
I don't see 3.2.5 in RHEL5 or in the RHEL5 beta channel on rhn... where should I
be looking, other than at linux.duke.edu
Comment 5 James Antill 2007-09-13 16:39:30 EDT
 Yeh, that's why I re-opened it. Hopefully we'll get 3.2.5 or so in for RHEL-5.2.

 I'm guessing Jeremy thought it was a Fedora bug.
Comment 6 Jim Perrin 2007-09-13 19:01:11 EDT
sounds good. if there's a beta package for RHEL5 later on, I'll happily test. 
Comment 7 RHEL Product and Program Management 2007-10-16 00:00:02 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Jan Hutař 2008-04-17 02:48:06 EDT
Hello Jim,
there is new yum (3.2.8-9.el5) in the 5.2 Beta channels on the RHN. It would be 
really great if you could test it because it is better to have more eyes on it.

Thank you,
Jan
Comment 12 James Antill 2008-04-17 12:10:48 EDT
 Ok, yeh I can confirm the bug here ... the problem is that it's an rpm thing.
From the yum side we go into:

rpm.TransactionSet(root).addInstall()

...and we never come out. There's no customer stuff hanging on this (and RHN
doesn't do mirrors), and I'm assuming panu doesn't want to fix this at this
point. So we should probably just remove the bug from the yum errata.
 I'll try and find out if we know when this got fixed in Fedora.
Comment 13 Denise Dumas 2008-04-22 08:39:26 EDT
Moving to 5.3 (and we may need to reassign to rpm) 
Comment 14 James Antill 2008-04-23 01:26:34 EDT
 Well it's still on the yum component, but I have a pretty big suspicion that
this is the same underlying bug as rhbz#429737 ... and so is a yum bug.
 Given that we don't have multiple servers, we only really need to make sure
that this works in what will be the 5.3 errata version ... and probably the
easiest thing to do is make sure the fix
(a726a9d7652fff46000b5ac19de50416ef342719) is tested against the 5.2 yum and/or
the latest upstream yum doesn't have the problem.
Comment 16 James Antill 2008-04-23 09:41:05 EDT
 Yeh, that's the one bug#442232 ... not sure why I like the other one so much :).

Comment 17 RHEL Product and Program Management 2008-06-02 16:37:23 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 22 errata-xmlrpc 2009-01-20 16:44:01 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0176.html

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