Bug#973861: apt: http acquire method still failing with "Undetermined error" or "Data left in the buffer"
Package: apt
Version: 2.1.18
Followup-For: Bug #973861
X-Debbugs-Cc: witold.baryluk@gmail.com, mirror@init7.net
I started getting this error recently too.
To the point that using live-build (that downloads ~6100 package in one
go) is not possible, because some package will fail to download and fail
entire apt install request.
This is related to keepalive.
For example most nginx server has keepalive_requests 100 by default. That
is, after serving 100 request, nginx server will close the connection.
This is because some dynamic memory allocated by nginx is allocated on
arenas that are tied to TCP connection, and they are never freed until
the connection is closed. This is a high performance design, but to
prevent leaks and abuse, the connection must be closed after some number
of requests.
Most tools (wget), respect the response from the server, close the
existing connection and open a new one. It is easy to see with wget -i -
and feeding the same file 10000 times. Every 100th request will start a
new TCP connection.
In apt this manifests as some XX00 request failing.
Get:4500 http://mirror.init7.net/debian bullseye/main amd64 libplymouth5 amd64 0.9.5-2 [108 kB]
Err:4500 http://mirror.init7.net/debian bullseye/main amd64 libplymouth5 amd64 0.9.5-2
Undetermined Error [IP: 2001:1620::1620 80]
Get:1600 http://mirror.init7.net/debian bullseye/main amd64 libastyle3 amd64 3.1-2+b1 [109 kB]
Err:1600 http://mirror.init7.net/debian bullseye/main amd64 libastyle3 amd64 3.1-2+b1]
Undetermined Error [IP: 2001:1620::1620 80]
This is repeatable and reproducible. I can try 10 times doing the
download, and every time the same file and number will fail. (Sometimes I
might get lucky and one of them will succeed, but not ther other).
I don't know why files 100, 200, 300, ... doesn't fail, but it looks like
some bug in apt in general.
(The above files do exist and are served correctly by the server).
Does apt use maybe HTTP pipelining in addition to keepalive, that causes
issues? Or maybe in general the retry logic is broken somehow.
I wasn't able to reproduce this issue with Fastly CDN or Apache 2.4,
probably because they use different keepalive request limit policy. It
might be a bug in nginx too. I am not sure. The server I was using
appears to be using nginx/1.14.2.
Regards,
Witold
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (no /etc/apt/preferences.d/* present) --
-- /etc/apt/sources.list --
deb http://mirror.init7.net/debian/ bullseye main non-free contrib
deb-src http://mirror.init7.net/debian/ bullseye main non-free contrib
-- (/etc/apt/sources.list.d/dbgsym.list present, but not submitted) --
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-1-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2019.1
ii gpgv 2.2.20-1
ii libapt-pkg6.0 2.1.18
ii libc6 2.31-9
ii libgcc-s1 10.2.1-6
ii libgnutls30 3.7.0-5
ii libseccomp2 2.5.1-1
ii libstdc++6 10.2.1-6
ii libsystemd0 247.2-4
Versions of packages apt recommends:
ii ca-certificates 20200601
Versions of packages apt suggests:
pn apt-doc <none>
ii dpkg-dev 1.20.7.1
ii gnupg 2.2.20-1
ii powermgmt-base 1.36
ii synaptic 0.90.2
-- no debconf information
Reply to: