So if you turn on Debug::pkgAcquire::Worker you should probably see it
fail after a @ Queue: Action combined for
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2003851
Title:
occasional hanging
The important point to note is that fetchAfter==0 is the default case if
we did not get retries, so every non-retried item has that value and we
don't want to cycle it. The loop's purpose is to find the smallest
timeout to wait for, as an _optimization_ to the select() call below,
such that if we
We're going to need to fix this properly rather than busy cycle the
queues outside the select loop.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2003851
Title:
occasional hanging 'apt-get update'
Following up again. Disabling retries reduced the frequency of this bug,
but didn't eliminate it.
On the other hand, the patch I shared does seem to fix the bug. No
occurrences since we shipped it ~2 weeks ago. I encourage others to try
it out.
--
You received this bug notification because you
I'm seeing the same problem on Ubuntu 22.04.4 LTS:
$ ps -eHo pid,ppid,etimes,command | grep -w [a]pt
3162391 1 3033258 /bin/sh /usr/lib/apt/apt.systemd.daily update
3162395 3162391 3033258 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held
update
3162423 3162395 3033257
This sounds like a race condition that leads to live lock, considering
that both gpgv and apt are waiting for the other end to speak at the
same time.
I assume the protocol between these is custom made for this connection.
How the protocol is supposed to prevent this live lock situation from
Following up, `Acquire::Retries=0` seems to be avoiding the bug in prod,
which strengthens my suspicion that it's related to retries.
As for the actual bug, when apt is hanging, I notice that the work queue
has items in it, but they have not been delegated to a worker. There is
a condition that
Hello, also affected by this.
I'm able to reproduce the bug using Walter's mock server. I suspect it
may be related to the retry code that kicks in when a transient error is
encountered (like a 503). Retries are enabled by default since apt
2.3.2, which seems to fit the regression window people
