On Sat, Aug 15, 2009 at 02:10:16AM -0400, Daniel Richard G. wrote:
> ----8<----
> Hit http://midnight jaunty-security Release.gpg
> Ign http://midnight jaunty-security/main Translation-en_US
> Err http://midnight jaunty-security/restricted Translation-en_US
> Error reading from server - read (104 Connection reset by peer)
> Ign http://midnight jaunty-security/universe Translation-en_US
> Err http://midnight jaunty-security/multiverse Translation-en_US
> Error reading from server. Remote end closed connection
> Hit http://midnight jaunty Release.gpg
> Ign http://midnight jaunty/free Translation-en_US
> ---->8----
>
> Whoops! Spoke too soon. There appears to be a completely separate
> failure mode that also leads to "Connection reset by peer" errors for
> nonexistent Translation* files. This one has nothing to do with
> pipelining (setting Pipeline-Depth to "0" doesn't help), and it looks a
> lot hairier to figure out, so I'll post my observations so far:
>
> 1. It's very easy to determine if this problem is affecting you: you get
> a big fat warning in your error.log file, even with debugging
> switched off:
>
> Sat Aug 15 01:34:17 2009|info [10743]: ALARM!
> /srv/apt-cacher/packages/ubuntu-security_dists_jaunty-security_main_i18n_Translation-en_US.bz2
> file is larger than expected (343). Renaming to
> /srv/apt-cacher/packages/ubuntu-security_dists_jaunty-security_main_i18n_Translation-en_US.bz2.corrupted.
>
> 2. The expected size in the above message is 343, as returned by the
> upstream server in the Content-Length: field. This reflects the size
> of the 404 error page.
>
> 3. The actual (unexpected) size here is 502 bytes, which reflects the
> combined size of the HTTP header AND body. apt-cacher is reading from
> a file that it expects to contain only the 404 body, but for some
> reason it has both header and body.
Could you check
/srv/apt-cacher/packages/ubuntu-security_dists_jaunty-security_main_i18n_Translation-en_US.bz2.corrupted
and verify the contents as header+body. Is the header or the body first?
If the body is first, then the truncate() call at line 1377 is failing,
or not being called. I can't see why that might happen, but it is
getting late!
> (Incidentally, while apt-cacher claims to be reading the 404-body
> file from $cfg->{cache_dir}/packages/, I've never managed to
> actually *see* such a file in there. Is this deleted immediately
> after being sent to the client or something?)
I think this happens at line 1438 in fetch_store().
Mark
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
