Bug 119415

Summary: up2date stops and does not restart download
Product: [Retired] Red Hat Linux Reporter: Jean-Dominique Delyon <bugzilla>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED CANTFIX QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: gafton, mattdm, mihai.ibanescu, wdawe
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-02 18:39:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 120092    

Description Jean-Dominique Delyon 2004-03-30 08:12:09 UTC
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).

Comment 1 Adrian Likins 2004-04-05 19:43:47 UTC
Newer versions of up2date include the ability to restart
partial incomplete downloads.

Comment 2 Wayne Dawe 2004-04-06 02:45:56 UTC
Well it doesn't work properly.

Comment 3 Wayne Dawe 2004-04-06 04:38:37 UTC
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.

Comment 4 Jean-Dominique Delyon 2004-04-10 10:05:09 UTC
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.

Comment 5 Bill Nottingham 2006-08-05 03:47:22 UTC
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.


Comment 7 Bill Nottingham 2007-01-02 18:39:01 UTC
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.