[Bug 1795614] Re: packagekit frontend locking

[Julian Andres Klode]

** Description changed:

  [Impact]
  PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
+ 
+ Frontend locking prevents race conditions between multiple dpkg
+ frontends, which can cause other frontends to be interrupted while they
+ are installing stuff.
  
  [Test case]
  1. Install a package
  2. Modify prerm to sleep
  3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
  
  [Regression potential]
  Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
  
  The patch also adds a call to LockInner() after the dpkg execution to
  make it reacquire "lock", this could fail. It should not have much
  impact however, as it only affects a single transaction AFAICT. It does
  reduce the risk of some frontend not implementing frontend locking from
  racing while we still hold the frontend lock, though.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to packagekit in Ubuntu.
https://bugs.launchpad.net/bugs/1795614

Title:
  packagekit frontend locking

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  Triaged
Status in packagekit source package in Bionic:
  Triaged
Status in packagekit source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.

  Frontend locking prevents race conditions between multiple dpkg
  frontends, which can cause other frontends to be interrupted while
  they are installing stuff.

  [Test case]
  1. Install a package
  2. Modify prerm to sleep
  3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).

  [Regression potential]
  Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.

  The patch also adds a call to LockInner() after the dpkg execution to
  make it reacquire "lock", this could fail. It should not have much
  impact however, as it only affects a single transaction AFAICT. It
  does reduce the risk of some frontend not implementing frontend
  locking from racing while we still hold the frontend lock, though.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1795614/+subscriptions