group.of.nepali.translators team mailing list archive

[Julian Andres Klode <1796081@xxxxxxxxxxxxxxxxxx>]

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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1796081

Title:
  dpkg frontend locking

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

Bug description:
  [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

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