** 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. + are installing stuff - the frontend loses the dpkg lock between dpkg + runs and the system ends up in a partially configured state. [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.
** 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 - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state. + + See bug 1781169 for more details on frontend locking. [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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795614 Title: packagekit frontend locking To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1795614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
