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:
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 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.
*** 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 failure" problem. It's much worse than just that.
https://lists.dulug.duke.edu/pipermail/yum-devel/2005-June/001359.html
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 [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 :)
*** 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?
FC5/x86_64 here.
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.
this should be fixed in 2.9.6 - due out soon.
Good one! :) This deserves bugzilla's first ever... *mexican wave*