Description
sudo apt update intermittently stalls for 20+ minutes on ubuntu-latest (Ubuntu 24.04)
because apt keeps retrying azure.archive.ubuntu.com, which returns Ign: for every index, before
falling back to archive.ubuntu.com.
The step never fails — it just hangs. Without an explicit timeout-minutes, the job runs toward the
6-hour default limit.
Evidence
Log excerpt from an affected step (step duration: 22m40s, entirely inside apt update, cancelled
manually — it never reached the following commands):
Ign:3 http://azure.archive.ubuntu.com/ubuntu noble-updates InRelease
Ign:4 http://azure.archive.ubuntu.com/ubuntu noble-backports InRelease
Ign:5 http://azure.archive.ubuntu.com/ubuntu noble-security InRelease
Ign:2 http://azure.archive.ubuntu.com/ubuntu noble InRelease
... (26 `Ign:` lines total against azure.archive.ubuntu.com)
Hit:2 https://archive.ubuntu.com/ubuntu noble InRelease
Get:3 https://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:4 https://archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:5 https://archive.ubuntu.com/ubuntu noble-security InRelease [126 kB]
##[error]The operation was canceled.
26 Ign: lines against the Azure mirror versus 13 Hit:/Get: on the fallback.
Frequency
Measured across the last 14 runs of one job in a single repository:
| duration |
runs |
| 3–4 min (normal) |
11 |
| 32 min |
1 |
| 80 min |
1 |
| 22 min (cancelled) |
1 |
Roughly 20% of runs were affected over a ~24-hour window. Two jobs in the same workflow run and
the same commit behaved differently — one completed the identical step in 1m56s while the other
stalled — which points at intermittent mirror reachability rather than anything in the workflow.
Expected behaviour
apt update should fail over to the working mirror quickly, or fail fast, rather than stalling for
tens of minutes.
Related (both closed)
Workaround, in case it helps others
Bounding apt's own retry/timeout behaviour makes the fallback happen in seconds, and treating the
step as non-fatal avoids blocking the job:
- name: Install dependencies
timeout-minutes: 10
run: |
APT_OPTS="-o Acquire::Retries=1 -o Acquire::http::Timeout=10 -o Acquire::https::Timeout=10"
timeout 90 sudo apt-get $APT_OPTS update -qq || echo "::warning::apt-get update timed out"
timeout 150 sudo apt-get $APT_OPTS install -y --no-install-recommends <packages> \
|| echo "::warning::apt-get install timed out"Adding timeout-minutes to the job is what turns a silent multi-hour hang into a fast, diagnosable
failure.
Description
sudo apt updateintermittently stalls for 20+ minutes onubuntu-latest(Ubuntu 24.04)because apt keeps retrying
azure.archive.ubuntu.com, which returnsIgn:for every index, beforefalling back to
archive.ubuntu.com.The step never fails — it just hangs. Without an explicit
timeout-minutes, the job runs toward the6-hour default limit.
Evidence
Log excerpt from an affected step (step duration: 22m40s, entirely inside
apt update, cancelledmanually — it never reached the following commands):
26
Ign:lines against the Azure mirror versus 13Hit:/Get:on the fallback.Frequency
Measured across the last 14 runs of one job in a single repository:
Roughly 20% of runs were affected over a ~24-hour window. Two jobs in the same workflow run and
the same commit behaved differently — one completed the identical step in 1m56s while the other
stalled — which points at intermittent mirror reachability rather than anything in the workflow.
Expected behaviour
apt updateshould fail over to the working mirror quickly, or fail fast, rather than stalling fortens of minutes.
Related (both closed)
apt-get updatefailed on the latest ubuntu-22.04 image (2022.05.29.1) #5656 —apt-get updatefailed on the latest ubuntu-22.04 imageWorkaround, in case it helps others
Bounding apt's own retry/timeout behaviour makes the fallback happen in seconds, and treating the
step as non-fatal avoids blocking the job:
Adding
timeout-minutesto the job is what turns a silent multi-hour hang into a fast, diagnosablefailure.