This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 139459 - (yumctrlc) yum fails to differentiate between user cancel and download failure
yum fails to differentiate between user cancel and download failure
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
: 139254 142004 152155 159205 164452 168835 174264 189108 190254 (view as bug list)
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2004-11-15 22:20 EST by Rahul Sundaram
Modified: 2014-01-21 17:50 EST (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 10:19:31 EDT
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 Rahul Sundaram 2004-11-15 22:20:48 EST
Description of problem:

yum in fc3 has a mirror switching ability when it fails to download a
particular package (presumably because the mirror was not properly
updated). unfortunately it doesnt differentiate between user cancel an
this. I try to cancel a download in the middle and it simply calls it
a IO error and switches to a new mirror.

Version-Release number of selected component (if applicable):


How reproducible:

everytime

Steps to Reproduce:
1. yum  install packge
2. control+c in the middle of a download

  
Actual results:

switches to a new mirror

Expected results:

Exit on user cancel

Additional info:
Comment 1 Seth Vidal 2004-11-15 22:30:39 EST
it's technically expected behavior. Trying to come up with a good way
to allow skipping to the next mirror w/o cancelling and still allow
for a normal user break.
Comment 2 Sitsofe Wheeler 2004-11-20 12:47:19 EST
This sounds like it's related to bug 139254
Comment 3 Seth Vidal 2005-06-19 02:54:56 EDT
*** Bug 159205 has been marked as a duplicate of this bug. ***
Comment 4 Rahul Sundaram 2005-06-20 14:11:17 EDT
*** Bug 139254 has been marked as a duplicate of this bug. ***
Comment 5 Rahul Sundaram 2005-06-20 14:54:38 EDT
*** Bug 152155 has been marked as a duplicate of this bug. ***
Comment 6 Need Real Name 2005-06-20 15:03:57 EDT
(In reply to comment #1)
> it's technically expected behavior. Trying to come up with a good way
> to allow skipping to the next mirror w/o cancelling and still allow
> for a normal user break.
> 

Since my bug was closed, I'll comment here.
It's technically unexpected behaviour because ^C means "please die".
We need another access key for skip mirror, reusing something that is meant to
kill a program isn't user friendly or good.
Comment 7 Rahul Sundaram 2005-06-21 07:57:57 EDT
A clarification: Your original bug report was closed because it was marked as a
duplicate. It does not mean that its a invalid one

I believe you have misunderstood Seth's comment on this being technically
expected behaviour. Yum has a feature that detects if the mirror is not
accessible or interrupted and switches to a new one in the mirror list in a
random fashion. However this mirror interrupt is hard to differentiate from user
interrupt through ^C as I understand it. 

The solution might be to stop over N number of interrupts assuming that its from
the user and not a mirror failure. The user might just be interrupting in order
for yum to switch over to a hopefully faster mirror on its next try. This is a
trick issue to resolve
Comment 8 Need Real Name 2005-06-21 09:47:36 EDT
Some suggestions from other users:
 "Alternatively, if you Ctrl-C more than once for the same mirror, abort."
 "If you Ctrl-C twice within x seconds, abort."

It's an easy issue to resolve because ^C shouldn't be overloaded.
Comment 9 Colin Charles 2005-08-19 00:02:36 EDT
*** Bug 164452 has been marked as a duplicate of this bug. ***
Comment 10 Need Real Name 2005-08-24 12:11:11 EDT
(In reply to comment #0)
> Actual results:
> switches to a new mirror
> 
> Expected results:
> Exit on user cancel
> 

For me, the actual result is that it switches a mirror, and then aborts before
installing the downloaded rpms.
So now the intended cancel fails, as well as the mirror switch.
Comment 11 Rahul Sundaram 2005-08-27 15:35:39 EDT
*** Bug 164452 has been marked as a duplicate of this bug. ***
Comment 12 Fergal Daly 2005-08-28 06:52:51 EDT
There are 2 problems:

1 - signals are being ignored. So for example sending certain signals causes

[Errno 4] Socket Error: (4, 'Interrupted system call')

when it should really cause the program to exit. SIGINT and SIGTERM are being
ignored but SIGALRM is not.

The socket errors are caused by signals being delivered during a system call,
when this happens you are supposed to retry the call. Which brings me to the
second bug:

2 - when read() returns EINTR it means you should attempt the read again.
urlgrabber doesn't attempt it again, it assumes that all errors are fatal and
switches to another mirror. Fixing this would mean that ctrl-c doesn't switch to
another mirror.

--

It's possible that you consider no 2 there to be a feature rather than a bug
because it allows users to switch mirrors but that doesn't explain why SIGINT
_and_ SIGTERM are being ignored.

At least if SIGTERM caused a quit I could ctrl-z and kill %1 to kill yum rather
than digging around with ps.
Comment 13 Jeremy Katz 2005-09-21 15:22:26 EDT
*** Bug 142004 has been marked as a duplicate of this bug. ***
Comment 14 Jeremy Katz 2005-09-21 15:44:46 EDT
*** Bug 168835 has been marked as a duplicate of this bug. ***
Comment 15 Rahul Sundaram 2005-11-26 17:32:49 EST
*** Bug 174264 has been marked as a duplicate of this bug. ***
Comment 16 Roland McGrath 2005-11-26 17:36:10 EST
My bug was closed as a dup of this one, but this one talks only about
interrupting downloads.  Yum cannot be interrupted properly no matter what it is
doing, even when it is not doing anything at all like downloading.  The bug I
reported is not merely the "differentiate between user cancel and download
failure" problem.
It's much worse than just that.
Comment 18 Need Real Name 2006-01-20 16:23:10 EST
We're up to FC5T2 now, and I still can't kill yum by following the standard
procedure of pressing Control+C.

Instead, I have to run Ctrl+Z, then run kill -9 %1. ARGHH!
Comment 19 Ignacio Vazquez-Abrams 2006-04-16 07:44:48 EDT
*** Bug 189108 has been marked as a duplicate of this bug. ***
Comment 20 Adam Pribyl 2006-04-20 08:56:17 EDT
This problem annoys me for long time. I'd really appreciate the behaviour
described in mail from comment #17 to be implemented.
Comment 21 Gilboa Davara 2006-04-25 08:58:08 EDT
I don't know if it's possible, but I rather see the following:
1. User sends a Ctrl-C.
2. Yum prints out: "Interrupt detect. Exit/Change Mirror/Ignore [E/c/i]"
-. User types Enter and/or 'E/e', yum shuts down.
-. User types 'C/c', yum changes mirror.
-. User types 'I/i', yum continues to work as usual.

SIGABRT (Ctrl-\) should kill yum; no question asked.
Comment 22 Need Real Name 2006-04-25 09:49:33 EDT
(In reply to comment #21)
> I don't know if it's possible
[snip]
> SIGABRT (Ctrl-\) should kill yum; no question asked.

SIGTERM (^C) is the standard way for asking the program to terminate.
SIGABRT causes an abnormal program termination and dumps core (by default). It's
also not a well-known shortcut, so I'm not sure why we should ditch standard ^C
exit behaviour and replace it with a mirror switching utility, then adopt a new
shortcut for doing what ^C should have done.

But then I'm not writing the code :)
Comment 23 Jeremy Katz 2006-04-29 09:23:16 EDT
*** Bug 190254 has been marked as a duplicate of this bug. ***
Comment 24 Zack Cerza 2006-08-24 11:53:39 EDT
Any word on this? Or a workaround? What's the preferred way to exit yum?
Comment 25 Need Real Name 2006-08-30 17:46:09 EDT
(In reply to comment #24)
> Any word on this? Or a workaround? What's the preferred way to exit yum?

No word at all! You could ^Z background it, then kill %1 it, that seems to be
the best way. Or if it's a gnome-terminal, close the window. Or ask the kernel
to forcably remove it's resources with killall -9 yum.

This 2004 bug isn't marked as a WILL be fixed for the next version of Fedora
Core, it's only a SHOULD fix.
Comment 26 Graham Leggett 2006-08-31 04:35:40 EDT
This bug casts serious doubt as to the quality of the yum package. If it can't
get simple ^C right, why would it get package management right?
Comment 27 Gilboa Davara 2006-08-31 05:48:01 EDT
I just posted a message about this bug in the -devel ML.
Comment 28 Seth Vidal 2006-08-31 07:41:06 EDT
Are you using yum 2.9.5 or higher from cvs?
Comment 29 Gilboa Davara 2006-08-31 09:49:12 EDT
FC5/x86_64 here.
Comment 30 Need Real Name 2006-09-01 03:18:39 EDT
Off-topic slightly, but I've never seen ^C just switch the mirror, it's always
switched the mirror, then aborted without doing anything with the packages it
downloaded.
So the above advertised behaviour of ^C switching mirror has never done what was
discussed anyway..... at least for me. Using yum 2.6.1-0 atm.
Comment 31 Seth Vidal 2006-09-05 10:19:31 EDT
this should be fixed in 2.9.6 - due out soon.
Comment 32 Need Real Name 2006-09-05 10:35:45 EDT
Good one! :)
This deserves bugzilla's first ever... *mexican wave*

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