Bug#1019934: apt-get gets stuck on unreachable proxy for https sources
Package: apt
Version: 2.5.2
Hey everyone,
I work in an environment with an APT mirror on the intranet, from where
clients pull their regular updates.
The mirror is configured to be reached via the DIRECT pseudo proxy in
apt.conf.d, while all 3rd party sources are supposed to be reached by an
HTTP proxy, also configured in apt.conf.d.
The clients are at times not connected to the VPN or intranet, and
there's a split-DNS wildcard record in place on the internet side of
things (beyond my control something something Letsencrypt) that leads to
them being redirected to a bogus central HTTPS homepage, which they then
try to reach by proxy, although the proxy itself is not reachable from
the outside. In this situation, scheduled update activity, mainly from
packagekit.service or from apt-daily.timer, leads to eternal lock-ups of
apt-get that won't ever recover on their own. The clients are then
blocked from updating for as long as the stuck process remains active,
until someone kills it manually or the system reboots.
Steps to reproduce:
I have set up an HTTP redirect on http://team-frickel.de/mirror/ that
will redirect to a bogus https://example.com/mirror/:
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/mirror/
RewriteRule /mirror/(.*) https://example.com/$1 [R,L]
On the client, two sources.list files have been prepared at non-standard
locations:
/etc/apt/one-source.list:
deb http://team-frickel.de/mirror/ testing main
/etc/apt/two-sources.list:
deb http://team-frickel.de/mirror/ testing main
deb http://team-frickel.de/mirror/ testing-security main
Let's try updating using these lists, with an unresolvable default proxy
for https.
Attempting an update from the one-source.list configuration fails
gracefully and correctly complains about the unresolvable proxy:
# apt-get -o Dir::Etc::sourcelist=/etc/apt/one-source.list \
-o Acquire::https::proxy=http://proxy.invalid:3128 update
Ign:1 https://example.com testing InRelease
Ign:1 https://example.com testing InRelease
Ign:1 https://example.com testing InRelease
Err:1 https://example.com testing InRelease
Could not resolve 'proxy.invalid'
Reading package lists... Done
W: Failed to fetch http://team-frickel.de/mirror/dists/testing/InRelease
Could not resolve 'proxy.invalid'
W: Some index files failed to download. They have been ignored, or old
ones used instead.
Moving on to the two-sources.list configuration, the operation gets
stuck at "0% [Working]" until interrupted:
# apt-get -o Dir::Etc::sourcelist=/etc/apt/two-sources.list \
-o Acquire::https::proxy=http://proxy.invalid:3128 update
Ign:1 https://example.com testing InRelease
0% [Working]
strace loops these lines while the process is stuck:
pselect6(7, [5 6], [], NULL, {tv_sec=0, tv_nsec=500000000}, NULL) = 0
(Timeout)
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
0% [Working]) = 1313
I believe this is a bug because if apt-get gracefully handles the error
when operating on a single APT source, it would seem logical to not get
stuck when operating on multiple sources.
The behaviour was initially observed on Ubuntu 22.04 (apt 2.4.7). It's
not reproducible on Debian 11 (apt 2.2.4) and Ubuntu 20.04 (apt 2.0.9),
but it is immediately reproducible on Debian Testing as of apt 2.5.2,
which is why I'm reporting it as a Debian bug.
The changelog shows that there was work done on https proxy evaluation
in apt 2.3.10 following bug #990555, so maybe this is a regression from
that change.
The redirect URL used for testing is up and does not log IP addresses or
any other client information.
Kind regards,
-martin
Reply to: