Bug#1012173: apt: Locking timeout for archives
On Tue, May 31, 2022 at 12:58:05PM +0200, Jouke Witteveen wrote:
> Package: apt
> Version: 2.0.8
> Severity: minor
>
> Dear Maintainer,
>
> In our setup, we share an archives cache directory [Dir::Cache::archives]
> between multiple (virtual) machines. This turns out to be an effective
> way to save bandwidth and disk space. However, each machine may lock the
> archives directory and make apt unavailable for the other machines. We had
> hoped that setting a lock timeout [DPkg::Lock::Timeout] would allow the
> other machines to wait on the one holding onto the lock. Unfortunately,
> that configuration parameter only applies to the 'admin directory'
> containing the status file. As a result, apt operations fail immediately
> when another machine holds a lock on the archives directory.
I do not consider sharing archives between machines to be a valid use
case. It breaks the assumptions of both the apt(8) model of cleaning up
after yourself as well as the opposite historical model of autoclean
(which removes packages no longer available from sources.list).
My suggestion for caching is to use a central squid-deb-proxy.
> We can think of a few ways to make the experience better.
> 1. Respect DPkg::Lock::Timeout also for the other apt locks
> (e.g. in apt-pkg/acquire.cc:pkgAcquire::GetLock).
> 2. Add a new lock configuration for the cache/archives
> (e.g. APT::Cache::Lock::Timeout).
> 3. Implement per-download locking with a timeout as requested in #478961.
>
> If either of these approaches is acceptable, we could propose an implementation
> if desired.
There are three locks at play in apt:
1. dpkg frontend lock - which apt always holds if it might invoke dpkg later on
2. dpkg lock - similar, but released to run dpkg
3. archives lock - held if we need to download anything
I implemented waiting for the outer most one, as we can somewhat easily
reason about this.
Some stuff might not lock the dpkg locks and that is problematic. Like
apt update should not change lists/ under me, and I should not be able
to acquire the archives/ lock without holding the frontend lock, as
otherwise I break the other process that just acquired the frontend
lock and now wants to install stuff.
I believe that all these different locks were essentially a mistake,
we really should have had just the one frontend lock.
The problem is, if the 2 dpkg locks succeed and we then get to the
archives lock, we can't go back to releasing the dpkg lock and waiting
for both of them, as we ought to.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: