#993291 apt upgrade crashes with "Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed" when not all mirrors are reachable

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Sven Bartscher
Date:
2021-09-10 07:57:03 UTC
Severity:
normal
#993291#5
Date:
2021-08-30 09:36:49 UTC
From:
To:
Hi,

APT seems to have trouble downloading packages, when not all configured
repositories are reachable. Attached is the result of running

sudo LC_ALL=C apt-get upgrade 2>&1 | tee apt.log

As you can see, at first apt-get (rightly) shows a lot of Ign lines for
mirror.home.weltraumschlangen.de, as that mirror is not reachable at the
moment. Then it crashes with a failed assertion at the end.

It is my understanding, that apt should deal with unreachable mirrors
gracefully and download packages from one of the available mirrors
instead. I also never had this problems before with this setup before
(including unreachable mirror), so I think this is a regression in apt
2.3.8.

When I move my device to a network location where all configured mirros
are available, the crash doesn't occur and I can successfully complete
the upgrade.

Using apt or apt-get doesn't seem to make a difference.

Regards
Sven

#993291#10
Date:
2021-08-31 09:28:25 UTC
From:
To:
Hi,

I completed the updates from yesterday using aptitude, which doesn't
seem to be affected by this bug. Updates from today went through
smoothly as expected, with the same mirror not reachable. So I'm not
sure how to reproduce this.

Fell free to close this bug if you can't reproduce it either.

Regards
Sven

#993291#15
Date:
2021-09-01 08:44:03 UTC
From:
To:
I can confirm the same issue here:

Ign:84 http://debian.debian.zugschlus.de/debian experimental/main Translation-en
22% [Working]apt: ../apt-pkg/acquire.cc:742: pkgAcquire::RunResult pkgAcquire::Run(int): Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed.
Aborted
(exit code 134)

The mirror in question is an apt-cacher-ng and it is reachable (split
DNS, so don't get confused by the name being a CNAME in global DNS).

Ths system I am seeing this on is a test system running sid, it was
updated a week before the bullseye release, and then partly upgraded a
week after the bullseye release. All this was successful. The apt update
following this partly completed upgrade fails now. I either get the
"Asstion failed" message, or apt simply stalls:

Ign:33 http://debian.debian.zugschlus.de/debian experimental/main all Contents (deb) T-2021-09-01-0801.19-F-2021-08-23-1401.28.pdiff
44% [Working]

I am prepared to let this system sit in this state until the weekend, so
if you want more debug information, please get back to me in the next
two days.

Greetings
Marc

#993291#20
Date:
2021-09-04 15:31:34 UTC
From:
To:
Looks like a transient issue here, today's apt update just went through.
I cannot reproduce the issue any more.

Greetings
Marc

#993291#23
Date:
2021-09-04 15:31:34 UTC
From:
To:
Looks like a transient issue here, today's apt update just went through.
I cannot reproduce the issue any more.

Greetings
Marc

#993291#28
Date:
2021-09-06 07:48:52 UTC
From:
To:
On Sat, 4 Sep 2021 17:31:34 +0200 Marc Haber <mh+debian-packages@zugschlus.de> wrote:


For me, the problem came back. As I mentioned earlier, some upgrades
went through smoothly for me. But a few days ago, upgrades started
failing again. But I have absolutely no clue, what is causing this
difference in behavior.

My mirror in question (mirror.home.weltraumschlangen.de) is also an
apt-cacher-ng with split DNS. If you're in the correct network segment,
the DNS returns a reachable IP address, otherwise it just returns NXDOMAIN.

Regards
Sven

#993291#33
Date:
2021-09-06 09:11:25 UTC
From:
To:
My hostname returns a CNAME to an official mirror if you're
somewhere[tm], and an A/AAAA for an apt-cacher-ng if you're in my home
network.

The machine where I have seen the issue hasn't been outside the home
network in years. It's a notebook, but one I use exclusively for
testing.

Greetings
Marc

#993291#38
Date:
2021-09-10 07:55:22 UTC
From:
To:
This only happens on retries due to network failures, so in apt 2.2,
the download would have failed anyway. It happens because APT tried
to retry an item that failed before and that it then delayed the retry
off, and _somehow_ the retry did not succeed.

2.3.9 lessens the severity of the issue, by turning the assert into
a warning, but it might lead to the process hanging. It should give
us the ability to see what happens, hopefully.