Public bug reported: [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 - aptdaemon (no bug filed yet) Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html ** Affects: dpkg (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: dpkg (Ubuntu Xenial) Importance: Undecided Status: Triaged ** Affects: dpkg (Ubuntu Bionic) Importance: Undecided Status: Triaged ** Affects: dpkg (Ubuntu Cosmic) Importance: Undecided Status: Fix Released ** 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 (this bug) + - dpkg (bug 1796081) - apt (bug 1781169) - python-apt (bug 1795407) - packagekit (bug 1795614) - unattended-upgrades - aptdaemon (no bug filed yet) Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html ** Also affects: dpkg (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: dpkg (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: dpkg (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: dpkg (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: dpkg (Ubuntu Bionic) Status: New => Triaged ** Changed in: dpkg (Ubuntu Xenial) Status: New => Triaged -- 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
