git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jak@xxxxxxxxxx: Frontend locking in APT clients]


Regarding stable releases. I plan to backport the dpkg, apt, and
python-apt changes to bionic and xenial. It will be worth it, and
together with a fix in u-u and aptdaemon and packagekit, we will
be looking at I guess 99% of issues with lock races fixed.

While I'm at it, I want to note that apt in its current merge request state,
automatically sets DPKG_FRONTEND_LOCKED when invoking dpkg
if the system lock is acquired (after the fork, directly
before the execvp). If you run dpkg yourself, like for calling
dpkg --configure -a you will probably have to set the environment
variable yourself.


On Mon, Jun 18, 2018 at 08:20:04PM +0200, Julian Andres Klode wrote:
> Forwarding this to ubuntu-devel.
> 
> ----- Forwarded message from Julian Andres Klode <jak at debian.org> -----
> 
> Date: Mon, 18 Jun 2018 20:19:17 +0200
> From: Julian Andres Klode <jak at debian.org>
> To: deity at lists.debian.org, debian-dpkg at lists.debian.org
> Subject: Frontend locking in APT clients
> Message-ID: <20180618200724.GA22225 at debian.org>
> Accept-Language: de-DE, de, en-GB, en-US, en
> User-Agent: NeoMutt/20180512
> 
> Hi folks,
> 
> With frontend locking in dpkg git, I think it's time I clear up
> some potential confusion as to how this is supposed to work in the
> APT world.
> 
> The idea is that the current _system->Lock() / apt_pkg.SystemLock
> / apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
> and lock, and new methods LockInner() and UnlockInner() will be
> provided to release "lock". Code running dpkg will need to call
> those around dpkg runs, rather than the generic Lock ones.
> 
> python-apt is currently broken in that you need to release the lock
> prior to calling commit() on an apt.Cache. This will change soon
> - no unlocking will be needed. A python-apt (>> 1.7~alpha1~) client
> should behave as following:
> 
> Basically, add Depends: python-apt (>> 1.7~alpha1~), and do:
>   with apt_pkg.SystemLock():
>     main()
> - forget about locks if you don't invoke dpkg manually - do not
> release that, ever. If you do run dpkg manually do it like this:
> 
>   with apt_pkg.NoInnerLock():
>     subprocess.check_call(["dpkg", "--configure", "-a"])
> 
> or instead of context managers, use the functions
> pkgsystem_{un,}lock{,_inner}.
> 
> This will ensure that your apt client will be safe against
> any other apt client, and any other client implementing frontend
> locking. It will not be safe against other frontends that acquire
> the dpkg lock themselves, those will need fixing too. It will however,
> be safe against concurrent runs of dpkg by users or frontends not
> implementing locking.
> 
> Thanks,
> Julian
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer                              i speak de, en
> 
> ----- End forwarded message -----
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer                              i speak de, en

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en