Hide Forgot
Description of problem: Downloaded F12 Alpha livecd, tried yum provides */firefox. yum starts downloading filecache; press Ctrl+C, it keeps moving to next mirrors till it runs out of them and then drops to the prompt.
pressing ctrl-c is SUPPOSED to skip to the next mirror. Pressing it twice in quick succession should drop you from the run.
Forgot to mention -- I had the Ctrl-C pressed all the time. It did show up the 'press Ctrl-C again in the next 2 seconds' thing once but that didn't take effect as well.
okay. That is helpful to know. What ver of yum and python-urlgrabber are you using?
yum is 3.2.23-13.fc12 python-urlgrabber is 3.9.0-4.fc12 default from F12-alpha.
Thanks - if you could try the latest python-urlgrabber http://koji.fedoraproject.org/koji/buildinfo?buildID=127746 and see if it is better or unchanged.
With upgrade to that version of python-urlgrabber, the prompt to press Ctrl-C and stop the download is presented at the first press of Ctrl-C but entering any more Ctrl-Cs don't help -- it still goes and checks for other mirrors.
I alsa had this problem and found it quite annoying. But now it goes to the other extreme: First time ctrl-c is pressed yum exists - no skipping to next mirror. yum-3.2.23-15.fc12.noarch python-urlgrabber-3.9.0-8.fc12.noarch
I hope yum exists all the time ;) Could someone test this pkg: http://skvidal.fedorapeople.org/misc/python-urlgrabber-3.9.0-9.fc12.noarch.rpm and let me know if the situation improves or not?
yum4ever ... With the new python-urlgrabber I see the same ctrl-c-breaks-immediately behaviour with "yum install ..." as before. BUT I noted that with yumdownloader I see exactly the expected behaviour. (I don't know if it also worked before ...) yum-3.2.23-15.fc12.noarch python-urlgrabber-3.9.0-9.fc12.noarch
ctrl-c breaks immediately while downloading? Just to be clear - the repo yum is downloading from - does it have any mirrors or is just a single mirror/baseurl?
I can check that when I come home tonight. But for now I can say that I use the default "rawhide" repo spec. I think it is metalink based. Top priority might be ftp, if that makes any difference: <url protocol="ftp" type="ftp" location="DK" preference="100">ftp://ftp.crc.dk/pub/mirrors/fedora/linux/development/i386/os/repodata/repomd.xml</url> (Carlsberg doesn't give free beer away, but they do give free software away.)
hmm - maybe it is an ftp thing. I'll have to check that out. Most of my mirrors are http based so.. Can you tell me how many mirrors in your metalink list?
No FTP. HTTP. Plenty of mirrors. [root@localhost ~]# URLGRABBER_DEBUG=10 yum install -y kernel ... 2009-09-02 23:23:35,582 attempt 1/10: http://ftp.df.lth.se/pub/fedora/linux/development/i386/os/Packages/kernel-2.6.31-0.190.rc8.fc12.i686.rpm INFO:urlgrabber:attempt 1/10: http://ftp.df.lth.se/pub/fedora/linux/development/i386/os/Packages/kernel-2.6.31-0.190.rc8.fc12.i686.rpm 2009-09-02 23:23:35,582 opening local file "/var/cache/yum/rawhide/packages/kernel-2.6.31-0.190.rc8.fc12.i686.rpm" with mode ab INFO:urlgrabber:opening local file "/var/cache/yum/rawhide/packages/kernel-2.6.31-0.190.rc8.fc12.i686.rpm" with mode ab * About to connect() to ftp.df.lth.se port 80 (#0) * Trying 194.47.250.18... * connected * Connected to ftp.df.lth.se (194.47.250.18) port 80 (#0) > GET /pub/fedora/linux/development/i386/os/Packages/kernel-2.6.31-0.190.rc8.fc12.i686.rpm HTTP/1.1 Range: bytes=10392336- User-Agent: urlgrabber/3.9.0 yum/3.2.23 Host: ftp.df.lth.se Accept: */* < HTTP/1.1 206 Partial Content < Content-Type: application/octet-stream < Accept-Ranges: bytes < ETag: "1923542579" < Last-Modified: Sat, 29 Aug 2009 00:04:45 GMT < Content-Range: bytes 10392336-34042411/34042412 < Content-Length: 23650076 < Date: Wed, 02 Sep 2009 21:23:55 GMT < Server: lighttpd/1.4.23 < ^C[root@localhost ~]# 8.fc12.i686.rpm 31% [=================== ] 86 kB/s | 10 MB 04:22 ETA I notice that when stdout is redirected then ctrl-c doesn't work at all. yumdownloader do however show ugly traces when interrupted. And related and probably worse: abrt reports that as an error (because of the default error handler it installs). [root@localhost ~]# ULGRABBER_DEBUG=10 yumdownloader -y kernel Loaded plugins: fastestmirror, presto, refresh-packagekit, remove-with-leaves Loading mirror speeds from cached hostfile rawhide/metalink | 12 kB 00:00 * rawhide: ftp.df.lth.se * rpmfusion-free-rawhide: fedora.tu-chemnitz.de * rpmfusion-nonfree-rawhide: fedora.tu-chemnitz.de adobe-linux-i386 | 951 B 00:00 rpmfusion-free-rawhide | 3.8 kB 00:00 rpmfusion-nonfree-rawhide | 3.3 kB 00:00 ^CLocking '/var/cache/abrt/pyhook-1251927563-3325.lock'... 3% [=- ] 109 kB/s | 1.0 MB 04:54 ETA UnLocking '/var/cache/abrt/pyhook-1251927563-3325.lock'... Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1492, in _retrieve def _retrieve(self, buf): KeyboardInterrupt Current download cancelled, interrupt (ctrl-c) again within two seconds to exit. ^CTraceback (most recent call last):m 6% [===- ] 106 kB/s | 2.0 MB 04:55 ETA File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1492, in _retrieve def _retrieve(self, buf): KeyboardInterrupt ^CTraceback (most recent call last): File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1492, in _retrieve def _retrieve(self, buf): KeyboardInterrupt Traceback (most recent call last): File "/usr/bin/yumdownloader", line 315, in <module> util = YumDownloader() File "/usr/bin/yumdownloader", line 50, in __init__ self.main() File "/usr/bin/yumdownloader", line 87, in main self.downloadPackages(opts) File "/usr/bin/yumdownloader", line 244, in downloadPackages path = repo.getPackage(download, checkfunc=checkfunc) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 845, in getPackage cache=cache File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 818, in _getFile http_headers=headers, File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1024, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 945, in _retry cb_func(obj, *cb_args, **cb_kwargs) File "/usr/share/yum-cli/output.py", line 1149, in interrupt_callback raise KeyboardInterrupt KeyboardInterrupt
Oh. yum -y install yelp works (ctrl-c makes it continue with next mirror), but yum -y install kernel doesn't (ctrl-c breaks immediately). Does that explain anything? yum-3.2.24-2.fc12.noarch python-urlgrabber-3.9.0-9.fc12.noarch
*** Bug 522469 has been marked as a duplicate of this bug. ***
How my bug can be a dupe when I'm mentioning quite the opposite things - a regression from yum 3.2.22?
It's the same basic bug. You're using python-urlgrabber 3.9.0, right?
python-urlgrabber-3.0.0-15.fc11.noarch
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Thank you for taking the time to report this bug. Updates to this package have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing 'yum update yum' or using the graphical updater, Software Update. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm seeing the exact opposite - Ctrl-C no longer displays the "press Ctrl-C again" message - instead it simply quits. I'm using python-urlgrabber-3.9.1-4. Would it be possible to separate the "switch mirror" functionality from the "Abort" functionality by moving the "switch mirror" functionality to another combo? (E.g. Ctrl-S) - Gilboa
(In reply to comment #21) > > Would it be possible to separate the "switch mirror" functionality from the > "Abort" functionality by moving the "switch mirror" functionality to another > combo? (E.g. Ctrl-S) Please fill a bug asking for that functionality, this one is trying to make Ctrl-C to stop the process (as the title states). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #22) A. Please notice that this bug is a duplicate of the opposite bug (#522469) - read: Ctrl-C no longer lets to switch mirrors - it just dies. B. I wasn't offering a new feature - I was offering a -solution- to this bug. (Read: By separating the functionality of two distinct features). This solution may or may not be acceptable or even possible - but it's closely related to this bug. - Gilboa
I think the confusion is because the bug #522469 has been marked duplicated of this one but it's not. The problem of switching mirrors is related to this one but is a different one and should be treated differently (https://bugzilla.redhat.com/page.cgi?id=bug-writing.html). That's why I've reopening bug #522469 and associating to this one. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I would imagine that both bugs are triggered by a broken SIGINT handler - so in essence, that are the same. Never the less, as requested, I'll move to #522469. - Gilboa
I'm confused as to what bug this is, and why bug 522469 was closed. Anyway, in Rawhide now, Ctrl-C handling in yum is still broken: Ctrl-C once doesn't do anything immediately. After 10-20 seconds it prints: Current download cancelled, interrupt (ctrl-c) again within two seconds to exit. However, pressing Ctrl-C again does nothing at all. The only way to kill yum seems to be 'kill -9'. This has been a recurring theme in yum: http://www.google.com/search?q=yum+ctrl+c Why can't we fix this once and for all?
It's an on going bug b/c of the desire to have a single ctrl-c skip mirrors. Please, feel free to investigate it - it has a rather long and involved history.
"Pressing Ctrl-C while yum downloads something results in it going to next mirror instead of stopping" has been a function in YUM for a very long time. It is very useful for people you install fedora on laptops and do yum updates from different networks. It also is nice to be able to switch from a mirror that was fast previously but is currently slow to a possible faster mirror. If Ctrl-C is not an option then it would be nice for another key to be used to switch to another mirror. Changing the function of Ctrl-C is more of a feature request then an actual bug.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Since 2009-08-25 and still not solution. LOL, i remember, when i start to use Linux. I used to believe that the problem can be fixed in minutes... Anddd OMG, with the news speed of the intertet, the fix could be shared almost instantant to all users. Dreams, dreams, dream.
if you have a patch to solve this problem, feel free to attach it. thanks
While I do not agree with Splen's comment (or tone), as I said before, any attempt to fix this bug will most likely be short-lived, as the design itself (read: combining two separate functions: "Mirror switch" and "Abort" into a single short-cut) should be changed. Let me ask the opposite question: Would a patch changing the mirror switch to say, Ctrl-M, would have been accepted by up-stream? - Gilboa
Gilboa, If you've got a patch to solve this problem it will DEFINITELY get looked at. thanks,
I'm no python programmer (C), but I'll see if I can learn in on the fly while looking at this problem. - Gilboa
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. 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 prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
behaviour exists in f15 as well
Created attachment 573779 [details] my Smolt Profile
This bug seems present in Fedora 16 & Fedora 17 Alpha. Once a Yum session is started my computer never allows me to exit the session, no matter how many times I press <Ctl-C>. -Dave
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Me too on F17. yum is using a stale dns server (maybe another bug), so can't resolve any mirrors. Ctrl-C is ineffective no matter how often or frequently it's entered. $ rpm -q yum python-urlgrabber python-urlgrabber-3.9.1-11.fc17.noarch yum-3.4-23.fc17.noarch
Created attachment 592127 [details] better ctrl-c handling Well, when pycurl connects to a host, it blocks, even if user hits ctrl-c. We can't fix it in Python, and fixing this in libcurl is not easy. I've hacked a workaround using the non-blocking curl API. It will burn more CPU cycles, probably downloads slower, and might even break things, but ctrl-c response should be instantaneous. It will probably never go into Yum, but if anyone wants to test this during the weekend, I'd be happy.. Thanks!
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm seeing this bug in FC20. In the light of comment 41, could this bug be reopened?
(In reply to Peter H. Jones from comment #44) Yum is being replaced with DNF (which you can install right now) so reopening this bug makes little sense.