Connection closed, retrying on Packages.bz2 files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt-proxy (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: apt-proxy
This tool (the Karmic version) doesn't seem to get the caching of package information files right. When I run debootstrap over apt-proxy once, using ftp.de.debian.org as a backend, the directory /var/cache/
However, on subsequent calls, a combination of strange behaviour occurs. I've tested it by simply calling wget 'http://
* First of all, apt-proxy doesn't take the file from the cache, but instead tries to download it again.
* Second, it tries to download it twice, as can be confirmed with some ngrep logging:
####
T 192.168.0.8:55051 -> 141.76.2.4:80 [AP]
GET /debian/
###
T 192.168.0.8:55052 -> 141.76.2.4:80 [AP]
GET /debian/
* Third, one of the two streams seems to terminate, which might be a server-side policy. The manifestation of this issue on the user side looks as follows:
--2010-03-07 09:43:34-- http://
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|
HTTP request sent, awaiting response... 200 Streaming file
Length: 6175863 (5.9M) [text/plain]
Saving to: `Packages.bz2'
0% [ ] 4,041 --.-K/s in 0.01s
2010-03-07 09:43:34 (347 KB/s) - Connection closed at byte 4041. Retrying.
--2010-03-07 09:43:35-- (try: 2) http://
On the system side through apt-proxy.log, it looks as follows:
2010-03-07 09:43:34+0100 [TimeoutProtoco
2010-03-07 09:43:34+0100 [TimeoutProtoco
2010-03-07 09:43:34+0100 [TimeoutProtoco
2010-03-07 09:43:34+0100 [TimeoutProtoco
2010-03-07 09:43:34+0100 [TimeoutProtoco
Traceback (most recent call last):
File "/usr/lib/
return callWithContext
File "/usr/lib/
return context.
File "/usr/lib/
return self.currentCon
File "/usr/lib/
return func(*args,**kw)
--- <exception caught here> ---
File "/usr/lib/
why = getattr(selectable, method)()
File "/usr/lib/
return self.protocol.
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
return self.rawDataRec
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
return self.decompress
In summary, I think there are two main issues here: The tool doesn't honour the fact that it cached the Packages.bz2 file just a few moments before the second call, and the tool tries to download the file twice.
Another observation in combination with debootstrap: The Release file was taken from the cache, and therefore the size and MD5 sum of Packages.bz2 didn't match anymore as it changed on the server and was always retrieved from there. This causes debootstrap to fail. Looks like a direct effect of this bug.