[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.7~16.04.2 --- unattended-upgrades (1.1ubuntu1.18.04.7~16.04.2) xenial; urgency=medium * Don't check blacklist too early and report updates from not allowed origins as kept back. (LP: #1781176) * test/test_blacklisted_wrong_origin.py: Fix and enable test * Filter out progress indicator from dpkg log (LP: #1599646) * Clear cache when autoremoval fails (LP: #1779157) * Find autoremovable kernel packages using the patterns in APT's way (LP: #1815494) unattended-upgrades (1.1ubuntu1.18.04.7~16.04.1) xenial; urgency=medium * Start service after systemd-logind.service to be able to take inhibition lock (LP: #1806487) * Handle gracefully when logind is down (LP: #1806487) unattended-upgrades (1.1ubuntu1.18.04.7~16.04.0) xenial; urgency=medium * Backport to Xenial (LP: #1702793) * Revert to build-depending on debhelper (>= 9~) and dh-systemd * Revert configuration example changes to avoid triggering a debconf question * debian/postinst: Update recovery to be triggered on Xenial's package versions unattended-upgrades (1.1ubuntu1.18.04.7) bionic; urgency=medium * Trigger unattended-upgrade-shutdown actions with PrepareForShutdown() Performing upgrades in service's ExecStop did not work when the upgrades involved restarting services because systemd blocked other stop/start actions making maintainer scripts time out and be killed leaving a broken system behind. Running unattended-upgrades.service before shutdown.target as a oneshot service made it run after unmounting filesystems and scheduling services properly on shutdown is a complex problem and adding more services to the mix make it even more fragile. The solution of monitoring PrepareForShutdown() signal from DBus allows Unattended Upgrade to run _before_ the jobs related to shutdown are queued thus package upgrades can safely restart services without risking causing deadlocks or breaking part of the shutdown actions. Also ask running unattended-upgrades to stop when shutdown starts even in InstallOnShutdown mode and refactor most of unattended-upgrade-shutdown to UnattendedUpgradesShutdown class. (LP: #1778219) * Increase logind's InhibitDelayMaxSec to 30s. (LP: #1778219) This allows more time for unattended-upgrades to shut down gracefully or even install a few packages in InstallOnShutdown mode, but is still a big step back from the 30 minutes allowed for InstallOnShutdown previously. Users enabling InstallOnShutdown node are advised to increase InhibitDelayMaxSec even further possibly to 30 minutes. - Add NEWS entry about increasing InhibitDelayMaxSec and InstallOnShutdown changes * Ignore "W503 line break before binary operator" because it will become the best practice and breaks the build * Stop using ActionGroups, they interfere with apt.Cache.clear() causing all autoremovable packages to be handled as newly autoremovable ones and be removed by default. Dropping ActionGroup usage does not slow down the most frequent case of not having anything to upgrade and when there are packages to upgrade the gain is small compared to the actual package installation. Also collect autoremovable packages before adjusting candidates because that also changed .is_auto_removable attribute of some of them. (LP: #1803749) (Closes: #910874) unattended-upgrades (1.1ubuntu1.18.04.6) bionic; urgency=medium * Unlock for dpkg operations with apt_pkg.pkgsystem_unlock_inner() when it is available. Also stop running when reacquiring the lock fails. Thanks to Julian Andres Klode for original partial patch (LP: #1789637) * Skip rebuilding python-apt in upgrade autopkgtests. Python-apt has a new build dependency making the rebuilding as is failing and the reference handling issue is worked around in unattended-upgrades already. (LP: #1781586) * Stop trying when no adjustment could be made and adjust package candidates only to lower versions (LP: #1785093) * Skip already adjusted packages from being checked for readjusting. This makes it clearer that the recursion ends and can also be a bit quicker. (LP: #1785093) unattended-upgrades (1.1ubuntu1.18.04.5) bionic; urgency=medium * Stop updating the system when reacquiring the dpkg system lock fails. (LP: #1260041) unattended-upgrades (1.1ubuntu1.18.04.4) bionic; urgency=medium * Redirect stderr output in upgrade-between-snapshots, too, otherwise it breaks the test sometimes (LP: #1781446) unattended-upgrades (1.1ubuntu1.18.04.3) bionic; urgency=medium * Redirect stderr output in upgrade-all-security, otherwise it breaks the test (LP: #1781446) unattended-upgrades (1.1ubuntu1.18.04.2) bionic; urgency=medium [ Balint Reczey ] * Clear cache when autoremoval is invalid for a package set marked for removal and
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
There were no relevant changes between .1 and .2 thus marking this bug as verified on Xenial again. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Committed Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] This is part of a wider series of changes for frontend locking - dpkg (bug 1796081) - apt (bug 1781169) - python-apt (bug 1795407) - packagekit (bug 1795614) - 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1789637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
Hello Balint, or anyone else affected, Accepted unattended-upgrades into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source /unattended-upgrades/1.1ubuntu1.18.04.7~16.04.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Tags removed: verification-done verification-done-xenial ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Committed Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] This is part of a wider series of changes for frontend
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
As the log shows I actually tested with 1.1ubuntu1.18.04.7~16.04.1, the correct version. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Committed Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] This is part of a wider series of changes for frontend locking - dpkg (bug 1796081) - apt (bug 1781169) - python-apt (bug 1795407) - packagekit (bug 1795614) - 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1789637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
Tested 1.1ubuntu1.18.04.7~16.04.1:
Previous version:
root@x-uu-1789637-2:~# strace unattended-upgrade --verbose --dry-run 2>&1 |
grep lock
open("/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
open("/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 45
open("/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
Previous version with python3-apt supporting frontend lock:
root@x-uu-1789637-2:~# apt install -qq python3-apt
The following package was automatically installed and is no longer required:
libfreetype6
Use 'apt autoremove' to remove it.
Suggested packages:
python3-apt-dbg python-apt-doc
The following packages will be upgraded:
python3-apt
1 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 138 kB of archives.
After this operation, 6,144 B of additional disk space will be used.
(Reading database ... 25712 files and directories currently installed.)
Preparing to unpack .../python3-apt_1.1.0~beta1ubuntu0.16.04.3_amd64.deb ...
Unpacking python3-apt (1.1.0~beta1ubuntu0.16.04.3) over
(1.1.0~beta1ubuntu0.16.04.2) ...
Setting up python3-apt (1.1.0~beta1ubuntu0.16.04.3) ...
root@x-uu-1789637-2:~# strace unattended-upgrade --verbose --dry-run 2>&1 |
grep lock
open("/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
open("/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 45
open("/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
open("/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 48
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
Fixed version:
root@x-uu-1789637-2:~# apt install -qq unattended-upgrades
The following package was automatically installed and is no longer required:
libfreetype6
Use 'apt autoremove' to remove it.
Suggested packages:
bsd-mailx default-mta | mail-transport-agent needrestart
The following packages will be upgraded:
unattended-upgrades
1 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Need to get 40.2 kB of archives.
After this operation, 69.6 kB of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 25712 files and directories currently installed.)
Preparing to unpack .../unattended-upgrades_1.1ubuntu1.18.04.7~16.04.1_all.deb
...
Unpacking unattended-upgrades (1.1ubuntu1.18.04.7~16.04.1) over
(0.90ubuntu0.10) ...
Processing triggers for systemd (229-4ubuntu21.15) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up unattended-upgrades (:) ...
Installing new version of config file
/etc/kernel/postinst.d/unattended-upgrades ...
Installing new version of config file
/etc/pm/sleep.d/10_unattended-upgrades-hibernate ...
root@x-uu-1789637-2:~# strace unattended-upgrade --verbose --dry-run 2>&1 |
grep lock
open("/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
open("/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6
open("/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 50
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1789637
Title:
Proper support for frontend lock
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Bionic:
Fix Released
Bug description:
[Impact]
Apt and dpkg implemented the Frontend Locking API and unattended-
upgrades needs to adopt it to not leave the packaging system unlocked
while passing control to python-apt and dpkg to perform package
installations and removals. Leaving the packaging system unlocked
caused many crashes of u-u when other tools took the lock and in the
worse case let other package management tools operate on dpkg's
database breaking systems.
The change takes advantage of python-apt's new API and keeps the
frontend lock during the run of u-u and unlocks only the inner locks
for committing changes.
[Test case]
Run strace unattended-upgrades to upgrade several packages and check
that lock-frontend is acquired at the beginning and not released until
the end (not reacquired repeatedly).
Unfixed u-u's output is like this:
# strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock
openat(AT_FDCWD, "/var/run/unattended-upgrades.lock",
O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4
openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW,
0640) = 5
openat(AT_FDCWD,
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
Hello Balint, or anyone else affected, Accepted unattended-upgrades into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source /unattended-upgrades/1.1ubuntu1.18.04.7~16.04.0 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: unattended-upgrades (Ubuntu Xenial) Status: Confirmed => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Committed Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too.
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.6 --- unattended-upgrades (1.1ubuntu1.18.04.6) bionic; urgency=medium * Unlock for dpkg operations with apt_pkg.pkgsystem_unlock_inner() when it is available. Also stop running when reacquiring the lock fails. Thanks to Julian Andres Klode for original partial patch (LP: #1789637) * Skip rebuilding python-apt in upgrade autopkgtests. Python-apt has a new build dependency making the rebuilding as is failing and the reference handling issue is worked around in unattended-upgrades already. (LP: #1781586) * Stop trying when no adjustment could be made and adjust package candidates only to lower versions (LP: #1785093) * Skip already adjusted packages from being checked for readjusting. This makes it clearer that the recursion ends and can also be a bit quicker. (LP: #1785093) -- Balint Reczey Tue, 02 Oct 2018 19:18:02 +0200 ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Confirmed Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] This is part of a wider series of changes for frontend locking - dpkg (bug 1796081) - apt (bug 1781169) - python-apt (bug 1795407) - packagekit (bug 1795614) - 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 To manage
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
Tested with 1.1ubuntu1.18.04.6: root@uu-frontend-lock:~# strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 37 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 root@uu-frontend-lock:~# apt-get install una unaccent unace-nonfreeunagiunagi-dev unar unaceunadfunagi-dbgunalz unattended-upgrades root@uu-frontend-lock:~# apt-get install unattended-upgrades Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: libfreetype6 Use 'apt autoremove' to remove it. Suggested packages: bsd-mailx default-mta | mail-transport-agent needrestart The following packages will be upgraded: unattended-upgrades 1 upgraded, 0 newly installed, 0 to remove and 23 not upgraded. Need to get 37.7 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 unattended-upgrades all 1.1ubuntu1.18.04.6 [37.7 kB] Fetched 37.7 kB in 0s (186 kB/s) Preconfiguring packages ... (Reading database ... 28996 files and directories currently installed.) Preparing to unpack .../unattended-upgrades_1.1ubuntu1.18.04.6_all.deb ... Unpacking unattended-upgrades (1.1ubuntu1.18.04.6) over (1.1ubuntu1.18.04.5) ... Processing triggers for ureadahead (0.100.0-20) ... Processing triggers for systemd (237-3ubuntu10.3) ... Setting up unattended-upgrades (1.1ubuntu1.18.04.6) ... Processing triggers for man-db (2.8.3-2) ... root@uu-frontend-lock:~# strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 37 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 root@uu-frontend-lock:~# ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Confirmed Status in unattended-upgrades source package in Bionic: Fix Committed Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD,
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
It wasn't clear from this bug report whether or not this is fixed in Cosmic but I did some detective work and yes it is, setting it to Fix Released. ** Changed in: unattended-upgrades (Ubuntu) Status: Confirmed => Fix Released ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Confirmed Status in unattended-upgrades source package in Bionic: Fix Committed Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non- blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] This is part of a wider series of changes for frontend locking - dpkg (bug 1796081) - apt (bug 1781169) - python-apt (bug 1795407) - packagekit (bug 1795614) - 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1789637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
** Description changed: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 ... Fixed u-u's output is like that: # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 ... [Regression potential] Incorrect lock API usage can make unattended-upgrades to crash, but it is unlikely to hang since the lock handling operations are non-blocking. Failing to reserve the locks can also cause problems by allowing other package management tools to install packages in parallel, but this problem existed in the past, too. [Additional Info] - Frontend lock support for apt and dpkg is tracked in LP: #1781169, this bug tracks unattended-upgrades changes + This is part of a wider series of changes for frontend locking + + - dpkg (bug 1796081) + - apt (bug 1781169) + - python-apt (bug 1795407) + - packagekit (bug 1795614) + - 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 ** Also affects: unattended-upgrades (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: unattended-upgrades (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: New => In Progress ** Changed in: unattended-upgrades (Ubuntu Xenial) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Confirmed Status in unattended-upgrades source package in Xenial: Confirmed Status in unattended-upgrades source package in Bionic: In Progress Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
** Description changed: - Frontend lock support for apt and dpkg is tracked in LP: #1781169, this - bug tracks unattended-upgrades changes + [Impact] + + Apt and dpkg implemented the Frontend Locking API and unattended- + upgrades needs to adopt it to not leave the packaging system unlocked + while passing control to python-apt and dpkg to perform package + installations and removals. Leaving the packaging system unlocked caused + many crashes of u-u when other tools took the lock and in the worse case + let other package management tools operate on dpkg's database breaking + systems. + + The change takes advantage of python-apt's new API and keeps the + frontend lock during the run of u-u and unlocks only the inner locks for + committing changes. + + [Test case] + + Run strace unattended-upgrades to upgrade several packages and check + that lock-frontend is acquired at the beginning and not released until + the end (not reacquired repeatedly). + + Unfixed u-u's output is like this: + # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock + openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 + openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 + openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 + openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 93 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 + openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 + openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 + ... + + Fixed u-u's output is like that: + # strace unattended-upgrade --dry-run --verbose 2>&1 | grep lock + openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 + openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 8 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 + openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 57 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 + openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 69 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 + openat(AT_FDCWD, "/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 70 + openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 10 + ... + + [Regression potential] + + Incorrect lock API usage can make unattended-upgrades to crash, but it + is unlikely to hang since the lock handling operations are non-blocking. + Failing to reserve the locks can also cause problems by allowing other + package management tools to install packages in parallel, but this + problem existed in the past, too. + + [Additional Info] + Frontend lock support for apt and dpkg is tracked in LP: #1781169, this bug tracks unattended-upgrades changes -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Confirmed Bug description: [Impact] Apt and dpkg implemented the Frontend Locking API and unattended- upgrades needs to adopt it to not leave the packaging system unlocked while passing control to python-apt and dpkg to perform package installations and removals. Leaving the packaging system unlocked caused many crashes of u-u when other tools took the lock and in the worse case let other package management tools operate on dpkg's database breaking systems. The change takes advantage of python-apt's new API and keeps the frontend lock during the run of u-u and unlocks only the inner locks for committing changes. [Test case] Run strace unattended-upgrades to upgrade several packages and check that lock-frontend is acquired at the beginning and not released until the end (not reacquired repeatedly). Unfixed u-u's output is like this: # strace unattended-upgrade --verbose --dry-run 2>&1 | grep lock openat(AT_FDCWD, "/var/run/unattended-upgrades.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 4 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD, "/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 6 openat(AT_FDCWD, "/var/lib/dpkg/lock-frontend", O_RDWR|O_CREAT|O_NOFOLLOW, 0640) = 5 openat(AT_FDCWD,
[Touch-packages] [Bug 1789637] Re: Proper support for frontend lock
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: unattended-upgrades (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1789637 Title: Proper support for frontend lock Status in unattended-upgrades package in Ubuntu: Confirmed Bug description: Frontend lock support for apt and dpkg is tracked in LP: #1781169, this bug tracks unattended-upgrades changes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1789637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
