Description of problem: yum does not try the next mirror when cntrl-c is pressed during the download of a rpm. Version-Release number of selected component (if applicable): 3.2.8 How reproducible: Always Steps to Reproduce: 1. yum install somepackage 2. while downloading hit cntrl-c Actual results: yum says trying another mirror but quits. Expected results: yum should try the next mirror and continue download. Additional info: example of my fedora.repo: [fedora] name=Fedora $releasever - $basearch failovermethod=roundrobin #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch enabled=1 retries=20 timeout=10 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY
I can confirm this bug for yum-3.2.8-2.fc8 and also in yum from rawhide.
This fixes it upstream, so I _assume_ rpm has done something recent-ishly. Florian, can you take a look? diff --git a/yum/__init__.py b/yum/__init__.py index efee839..6a5a20d 100644 --- a/yum/__init__.py +++ b/yum/__init__.py @@ -1074,6 +1074,8 @@ class YumBase(depsolve.Depsolve): if (self.conf.cache or repo_cached) and errors: return errors + import signal + signal.signal(signal.SIGINT, signal.default_int_handler) remote_pkgs.sort(mediasort) # This is kind of a hack and does nothing in non-Fedora versions, The best part of debugging it is the signal.getsignal(signal.SIGINT) caches the result ... assuming noone will set it behind python's back.
It's probably worth noting that I tried self.closeRpmDB() instead, and that didn't do anything.
Ok, so I tried downgrading rpm to: rpm.x86_64 4.4.2.2-3.fc8 installed rpm-build.x86_64 4.4.2.2-3.fc8 installed rpm-devel.i386 4.4.2.2-3.fc8 installed rpm-devel.x86_64 4.4.2.2-3.fc8 installed rpm-libs.x86_64 4.4.2.2-3.fc8 installed rpm-libs.i386 4.4.2.2-3.fc8 installed rpm-python.x86_64 4.4.2.2-3.fc8 installed ...which should be the Fed-8 GA version of rpm/rpm-libs/etc. but it still has the same problem, so I'm guessing we changed something so that rpm sees the C-c's now? This might also explain bug#240138
FYI, bug#240138 is that basically the same thing happens in RHEL-5.2 using 3.2.8-*
Ok, so adding some trace code to rpm/rpmio/rpmsq.c:rpmsqEnable() I see: y Loaded plugins r rpm takes SIGINT = ref 1 r rpm releases SIGINT = ref 0 y <pkgSack> y <Excluding Packages> etc. [...] y Setting up Upgrade Process r rpm takes SIGINT = ref 1 y Resolving Dependencies [...] y --> Finished Dependency Resolution r rpm takes SIGINT = ref 2 y --> Running transaction check [...] y Transaction Summary r rpm releases SIGINT = ref 1 y Total size: [...] ...and then the download happens.
So ignoring the first ref/unref. The first ref is from self.rpmdb.ts The second ref is from self.ts and then ts.dbMatch() in misc.get_running_kernel_version_release(). Committing a fix upstream to combine them, and delete it before the download happens.
yum-3.2.16-1.fc9 has been submitted as an update for Fedora 9
yum-3.2.16-2.fc9 has been submitted as an update for Fedora 9
yum-3.2.16-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.