From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 Description of problem: If your Internet connection gets disrupted or cut off somehow, when up2date is resolving dependencies for a yum repository, it will traceback -- and more importantly, the GUI will be frozen. Version-Release number of selected component (if applicable): up2date-3.9.10-2 How reproducible: Didn't try (yet; I want to submit this bug first) Steps to Reproduce: 1. Run up2date GUI 2. (may or may not be required) deselect any RHN channels, leaving only Yum channels selected 3. Select packages to be updated 4. While it's "Testing package set / solving RPM inter-dependencies", make sure your Internet connection gets disrupted somehow. Actual Results: Traceback (most recent call last): File "/usr/share/rhn/up2date_client/gui.py", line 1620, in onPackagePageNext ret = self.__packagePageDryRun() File "/usr/share/rhn/up2date_client/gui.py", line 1548, in __packagePageDryRun self.__refreshCallback) File "/usr/share/rhn/up2date_client/up2date.py", line 469, in dryRun ret = depsolve.solvedep() File "/usr/share/rhn/up2date_client/depSolver.py", line 634, in solvedep ret = self.process_deps(deps) File "/usr/share/rhn/up2date_client/depSolver.py", line 601, in process_deps changed = self.__dependencies(dependencies) File "/usr/share/rhn/up2date_client/depSolver.py", line 447, in __dependencies refreshCallback = self.refreshCallback) File "/usr/share/rhn/up2date_client/depSolver.py", line 94, in solveDep ret = source.solveDep(unknowns, availList, refreshCallback) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 42, in solveDep self.getSolutions(unknowns) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 203, in getSolutions hdr = self.getHeader(pkg) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 186, in getHeader progressCallback = progressCallback) File "/usr/share/rhn/up2date_client/rpcServer.py", line 114, in doCall ret = apply(method, args, kwargs) File "/usr/share/rhn/up2date_client/repoDirector.py", line 36, in getHeader return self.handlers[channel['type']].getHeader(pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpmSource.py", line 210, in getHeader header = source.getHeader(pkg, progressCallback = progressCallback) File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line 108, in getHeader (fn, h) = urllib.urlretrieve(url) File "/usr/lib/python2.2/urllib.py", line 80, in urlretrieve return _urlopener.retrieve(url, filename, reporthook, data) File "/usr/lib/python2.2/urllib.py", line 210, in retrieve fp = self.open(url, data) File "/usr/lib/python2.2/urllib.py", line 178, in open return getattr(self, name)(url) File "/usr/lib/python2.2/urllib.py", line 292, in open_http h.endheaders() File "/usr/lib/python2.2/httplib.py", line 695, in endheaders self._send_output() File "/usr/lib/python2.2/httplib.py", line 581, in _send_output self.send(msg) File "/usr/lib/python2.2/httplib.py", line 548, in send self.connect() File "/usr/lib/python2.2/httplib.py", line 532, in connect raise socket.error, msg IOError: [Errno socket error] (110, 'Connection timed out') Expected Results: I was hoping for a more user-friendly error -- at LEAST don't just freeze up! I could have been racking up ISDN charges while waiting for the frozen client. *Especially* if I hadn't started up2date from a gnome-terminal. Additional info: This is really another way of triggering bug 88349. (Maybe it's even a dupe? I'm not sure.) Since this one is triggered by adverse but all-too-commonplace Internet problems, IMO it's a lot more serious than the generally unrealistic scenario that's needed for bug 88349 as I originally discovered it.
Yes, this one is reproducible (with yum repository, haven't tried testing RHN [Current] repo yet). To reproduce it, I replaced step 4 with "while it's resolving deps, unplug the Ethernet cable from your computer". Here's the traceback this time (it's different): Traceback (most recent call last): File "/usr/share/rhn/up2date_client/gui.py", line 1620, in onPackagePageNext ret = self.__packagePageDryRun() File "/usr/share/rhn/up2date_client/gui.py", line 1548, in __packagePageDryRun self.__refreshCallback) File "/usr/share/rhn/up2date_client/up2date.py", line 469, in dryRun ret = depsolve.solvedep() File "/usr/share/rhn/up2date_client/depSolver.py", line 634, in solvedep ret = self.process_deps(deps) File "/usr/share/rhn/up2date_client/depSolver.py", line 601, in process_deps changed = self.__dependencies(dependencies) File "/usr/share/rhn/up2date_client/depSolver.py", line 447, in __dependencies refreshCallback = self.refreshCallback) File "/usr/share/rhn/up2date_client/depSolver.py", line 94, in solveDep ret = source.solveDep(unknowns, availList, refreshCallback) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 42, in solveDep self.getSolutions(unknowns) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 203, in getSolutions hdr = self.getHeader(pkg) File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 183, in getHeader self.repos = repoDirector.initRepoDirector() File "/usr/share/rhn/up2date_client/repoDirector.py", line 65, in initRepoDirector up2dateRepo.register(rd) File "/usr/share/rhn/up2date_client/repoBackends/up2dateRepo.py", line 278, in register up2dateRepo = Up2dateRepo() File "/usr/share/rhn/up2date_client/repoBackends/up2dateRepo.py", line 236, in __init__ li = up2dateAuth.login() File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 112, in login loginInfo = rpcServer.doCall(server.up2date.login, systemId) File "/usr/share/rhn/up2date_client/rpcServer.py", line 124, in doCall raise up2dateErrors.CommunicationError(e.args[1]) up2dateErrors.CommunicationError: Error communicating with server. The message was: Temporary failure in name resolution
Indeed, the bug is reproducible with both yum and RHN repositories.
This might be the same as Bug 89252
I'll take a look. Error handling for network failures for yum/apt is basically totally broken at the moment.
I found a similar problem: I recently reinstalled Fedora Core 1 and I tried to download all the updates at once. If I check "all packets" only few are downloaded (often slow, 10-12 kbyte/s, but I'm not sure if this is a problem due to server bandwidth), then up2date freezes (no activity of internet connection and the window isn't refreshed). Then I kill the process, restart up2date, check only packages already downloaded and install them. Restart up2date, check the remaining packages and it starts downloading them.
For the benefit of the peanut gallery, I'll mention that this (or something very similar) is still present in FC3 & FC4t2. (I don't think I've tried reproducing on FC4t3 or later yet.)
'Red Hat Raw Hide' refers to the development tree for Red Hat Linux. Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues were not resolved in a more timely manner. However, we do want to make sure that important don't slip through the cracks. If these issues are still present in a current release, such as Fedora Core 5, please move these bugs to that product and version. Note that any remaining Red Hat Raw Hide bugs will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.