** Changed in: dpkg (Ubuntu Bionic)
Status: Triaged => In Progress
** Changed in: dpkg (Ubuntu Xenial)
Status: Triaged => In Progress
** Description changed:
[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently
acquire the dpkg "lock" lock file. They need to release it before running dpkg,
as dpkg also acquires it. Therefore, there is a race condition: In case the
application needs to run dpkg multiple times, another application could steal
the lock from under it, and the running application would fail in the middle of
the install, potentially rendering the system broken.
This fixes the problem by introducing an additional "lock-frontend" file
that frontends do not release when calling dpkg. When dpkg is not called
by a frontend using that file, it will try to acquire the frontend lock
as well, preventing it from interfering with such frontends.
[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should
succeed
[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can
only be expected in the form of that locking failing.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- - unattended-upgrades
+ - unattended-upgrades (bug 1789637)
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in
https://lists.debian.org/debian-dpkg/2017/01/msg00044.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796081
Title:
dpkg frontend locking
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1796081/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
