Bug 119415 - up2date stops and does not restart download
up2date stops and does not restart download
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
:
Depends On:
Blocks: 120092
  Show dependency treegraph
 
Reported: 2004-03-30 03:12 EST by Jean-Dominique Delyon
Modified: 2007-04-18 13:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 13:39:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jean-Dominique Delyon 2004-03-30 03:12:09 EST
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 15:43:47 EDT
Newer versions of up2date include the ability to restart
partial incomplete downloads.
Comment 2 Wayne Dawe 2004-04-05 22:45:56 EDT
Well it doesn't work properly.
Comment 3 Wayne Dawe 2004-04-06 00:38:37 EDT
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 06:05:09 EDT
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-04 23:47:22 EDT
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 13:39:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.