Hi, Same here with 3.7.4-1 on bookworm: when several machines run apt-get update in the same second, some get a 503 on InRelease, and the log has "Failure to move file ... out of the way" followed by "Error creating file item ... check file permissions!".
Looking at TFileItemRegistry::Create() in acregistry.cc (unchanged in 3.7.5), I see two problems. m_nTimeDlStarted stays 0 until the upstream headers arrive, so an index that is still downloading counts as stuck (now > 0 + stucksecs). Every new client moves it out of the way and downloads it again. The moved file is renamed to <path>.<now>, with now in seconds. Two moves in the same second pick the same name, link() fails with EEXIST, and the client gets the 503. The attached patch sets m_nTimeDlStarted when the item is created and adds a counter to the name. It builds on 3.7.4-1. We're about to deploy it together with Tim's patch from this bug, which applies on top as is. Without rebuilding, a very high ResponseFreezeDetectTime avoids the first problem, but then a download that is really stuck is never replaced. Godefroy
--- a/src/acregistry.cc +++ b/src/acregistry.cc @@ -144,6 +144,8 @@ auto sp(make_shared<fileitem_with_storage>(sPathRel)); sp->usercount++; sp->m_spattr = spattr; + // Without this, an item still waiting for upstream headers (0) looks stuck and every parallel client displaces it. + sp->m_nTimeDlStarted = GetTime(); auto res = mapItems.emplace(sPathRel, sp); ASSERT(res.second); @@ -216,7 +218,9 @@ // okay, have to move a probably existing cache file out of the way, // therefore needing this evasive maneuver - auto replPathRel = fi->m_sPathRel + "." + ltos(now); + // A seconds-only suffix collides (EEXIST, then 503) when two items for one path are displaced in the same second. + static unsigned long nDisplaced = 0; + auto replPathRel = fi->m_sPathRel + "." + ltos(now) + "." + ltos(++nDisplaced); auto replPathAbs = SABSPATH(replPathRel); auto pathAbs = SABSPATH(fi->m_sPathRel);
