Red Hat Bugzilla – Bug 139459
yum fails to differentiate between user cancel and download failure
Last modified: 2014-01-21 17:50:46 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):
Steps to Reproduce:
1. yum install packge
2. control+c in the middle of a download
switches to a new mirror
Exit on user cancel
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.
This sounds like it's related to bug 139254
*** Bug 159205 has been marked as a duplicate of this bug. ***
*** Bug 139254 has been marked as a duplicate of this bug. ***
*** Bug 152155 has been marked as a duplicate of this bug. ***
(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.
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
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.
*** Bug 164452 has been marked as a duplicate of this bug. ***
(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.
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
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
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.
*** Bug 142004 has been marked as a duplicate of this bug. ***
*** Bug 168835 has been marked as a duplicate of this bug. ***
*** Bug 174264 has been marked as a duplicate of this bug. ***
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
It's much worse than just that.
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!
*** Bug 189108 has been marked as a duplicate of this bug. ***
This problem annoys me for long time. I'd really appreciate the behaviour
described in mail from comment #17 to be implemented.
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.
(In reply to comment #21)
> I don't know if it's possible
> 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 :)
*** Bug 190254 has been marked as a duplicate of this bug. ***
Any word on this? Or a workaround? What's the preferred way to exit yum?
(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.
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?
I just posted a message about this bug in the -devel ML.
Are you using yum 2.9.5 or higher from cvs?
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
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.
this should be fixed in 2.9.6 - due out soon.
Good one! :)
This deserves bugzilla's first ever... *mexican wave*