On Thu, Apr 23, 2020 at 10:25 am, Eduard Bloch <e...@gmx.de> wrote:
Ok, guys, I still have no idea what is going on. While trying to hunt
your bug down, I found a couple of other important issues on the way,
but it is still not clear what happens in your case. Apart from the
fact
that the last TCP dump I saw was looking like sent trough a meat
grinder. In thousands of request, I saw this issue only once and I
figured that this file was pre-corrupted by another bug fixed in 3.4
and
the download was resumed later.
All three of us (and most of ruby-team) use this setup script.
https://salsa.debian.org/ruby-team/meta/-/blob/master/setup#L39
Here host machine's /var/cache/apt/archives is bind mounted in the
sbuild chroot. You can try this setup to reproduce the issue. So when a
download is incomplete due to internet brokage, I think apt somehow
does not resume download.
As for now, I can only suggest to make a few test runs with a
specially
instrumented version (see below). It enables the debug log stamps all
over the place even in release build. Some of them can be controlled,
therefore you should also set "debug=7" in the configuration.
When the issue was reproduced, please stop ASAP, collect the
/var/log/apt-cacher.err file and the suspicious package names or URLs
and the IP&hostname of the client machine. Don't forget to compress
apt-cacher.err, it might HUGE.
And then please reinstall the unmodified apt-cacher-ng version.
https://people.debian.org/~blade/experimental/apt-cacher-ng_3.5-1~1_amd64.deb
I will try this soon.
