From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 Description of problem: When, for any reason, the transfer is interrupted (maybe packet loss), up2date does not resume downloading and waits indefinitely. On my machine, I cannot laod anything greater than 2 MB. Version-Release number of selected component (if applicable): Last version downloaded 3 days ago How reproducible: Always Steps to Reproduce: 1. Start up2date 2. Select a package of more than 3 MB 3. Start downloading it and wait for a data transmissing problem. Actual Results: up2date is waiting indinitely. The timer is stopped. You must manually kill the transaction. Expected Results: up2date should either resume on-the-fly or, at least, resume at next transaction restart (when the same package is selected again for download). Currently, the software seems to be only able to detect an entirely downloaded but not installed package. Additional info: If the session is stopped (back to login) and resumed (new connection), the up2date transaction seems to be restarted but without any transfer. Having many up2date transactions sleeping seems to increase the reproductibility (it occurs more quickly).
Newer versions of up2date include the ability to restart partial incomplete downloads.
Well it doesn't work properly.
Sorry for the brevity of the last comment but when I saw that the bug had been closed without a resolution with the suggestion to update to the latest version when the original report said the latest version was being used I didn't count to 10 before I hit send. The behavior I see is on version 4.2.5-1 which is the latest. Large rpm downloads partway then stops with up2date in a unresponsive state. The same behavior occurs when run from the command line without the X windows interface. Checking /var/spool/up2date after breaking out of the hung up2date process does not show any partial download of the incomplete RPM. I'm not sure where up2date puts the incomplete download but when upd2date is run again it begins to download the whole RPM from the beginning. It stops partway through and the cycle continues ad infinitum. If there is a flag to enable the restarting of incomplete downloads I couldn't find any mention of it on the man page or in the command help.
As stated in last comment, resume is OK for a packages already downloaded, but still not installed, in a list of packages to download and install. But, for the partially downloaded package, the process is restarted from the beginning. Having started up2date from the command line of a shell in X mode (under KDE, I run the konsole command and, from that shell, I run up2date), I receive the following information immediately after the kill command: [root@Principal root]# up2date Traceback (most recent call last): File "/usr/share/rhn/up2date_client/gui.py", line 1611, in doRetrieval self.setRetrievalProgress) File "/usr/share/rhn/up2date_client/up2date.py", line 269, in getPackage buffer = rpcServer.doCall(rpmSource.psc.packageSource.getPackage, pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpcServer.py", line 114, in doCall ret = apply(method, args, kwargs) File "/usr/share/rhn/up2date_client/rpmSource.py", line 212, in getPackage package = source.getPackage(pkg, MsgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpmSource.py", line 697, in getPackage buffer = fd.read() File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 672, in read progressCallback=self.progressCallback) File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 437, in _smart_read chunk = fd.read(l) File "/usr/lib/python2.2/httplib.py", line 393, in read s = self.fp.read(amt) File "/usr/lib/python2.2/site-packages/rhn/SSL.py", line 161, in read data = self._connection.recv(self._buffer_size) SSL.WantReadError I hope it can help. Thakns in advance.
Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/) for security updates only. If this is a security issue, please reassign to the 'Fedora Legacy' product in bugzilla. Please note that Legacy security update support for these products will stop on December 31st, 2006. If this is not a security issue, please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. If you are currently still running Red Hat Linux 7.3 or 9, please note that Fedora Legacy security update support for these products will stop on December 31st, 2006. 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/. Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a security issue, please change the product as necessary. We thank you for your help, and apologize again that we haven't handled these issues to this point.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. f you are currently still running Red Hat Linux 7.3 or 9, 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.