Public bug reported:
[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.
[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.
** Affects: packagekit (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: packagekit (Ubuntu Xenial)
Importance: Undecided
Status: Triaged
** Affects: packagekit (Ubuntu Bionic)
Importance: Undecided
Status: Triaged
** Affects: packagekit (Ubuntu Cosmic)
Importance: Undecided
Status: Fix Released
** Also affects: packagekit (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: packagekit (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: packagekit (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: packagekit (Ubuntu Cosmic)
Status: New => Fix Released
** Changed in: packagekit (Ubuntu Bionic)
Status: New => Triaged
** Changed in: packagekit (Ubuntu Xenial)
Status: New => Triaged
** 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.
[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
+ 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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
