[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
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 1396787] Re: checking trust of archives eats a lot of cpu
The new bug: LP: #1824804 -- 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
@spvkgn Thanks! >From the log it seems this is not a loop, just applying the very high cost >fallback for each held package: ... Checking: linux-generic ([, ]) package linux-generic upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) falling back to marking linux-generic, then adjusting changes package linux-generic upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) falling back to adjusting all packages adjusting candidate version: 2ping=4.1-1 ... package linux-generic upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) sanity check failed for: set() Checking: linux-headers-generic ([, ]) package linux-headers-generic upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) falling back to marking linux-headers-generic, then adjusting changes package linux-headers-generic upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) falling back to adjusting all packages ... This is still a serious problem and opened a separate bug for it, but seems much better than an infinite loop. Can you please confirm that finally u-u finishes processing the packages? -- 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
@rbalint I've collect logs from both u-u packages. Latest u-u stucks in a loop. Please see zip attached. I have hold packages $ apt-mark showhold linux-generic linux-headers-generic linux-image-generic linux-libc-dev papirus-icon-theme ** Attachment added: "uu.zip" https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+attachment/5255891/+files/uu.zip -- 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
@spvkgn Could you please collect the logs of the upgrade where u-u 1.1ubuntu1.18.04.10 got stuck? Did you have any special origin or local package configured? If you could downgrade the packages which got upgraded could you please run 1.1ubuntu1.18.04.10 with --debug --verbose --download-only to see where it got stuck? -- 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
After update to 1.1ubuntu1.18.04.10 on Bionic "unattended-upgrades --download-only" using up 100% CPU and hangs. I tried to install previous version 1.1ubuntu1.18.04.9 and this issue is gone. ** Attachment added: "top-screenshot.png" https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+attachment/5255628/+files/top-screenshot.png -- 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
Verified with 1.1ubuntu1.18.04.7~16.04.2, measured times are similar to .1, verified previously. https://objectstorage.prodstack4-5.canonical.com /v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/unattended-upgrades/20190228_150449_11313@/log.gz ... Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial Packages that will be upgraded: 4.62user 0.16system 0:04.83elapsed 99%CPU (0avgtext+0avgdata 78264maxresident)k 0inputs+124024outputs (0major+38540minor)pagefaults 0swaps new packages marked as manually installed (should be none) ... ** 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
Hello Ernst, 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
Tested with 1.1ubuntu1.18.04.7~16.04.1: On the autopkgtest infrastructure u-u runs for 20s when all packages are installed from xenial-security but none from xenial-updates: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/unattended-upgrades/20181213_182038_2962e@/log.gz ... Starting unattended upgrades script Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial Packages that will be upgraded: 19.18user 1.17system 0:20.53elapsed 99%CPU (0avgtext+0avgdata 77720maxresident)k 0inputs+123512outputs (0major+38986minor)pagefaults 0swaps ... On a 2012 MacBook Air inside a KVM qemu vm autopkgtest runner it is ~8s: ... adt-2.log-Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial adt-2.log-Packages that will be upgraded: adt-2.log:7.64user 0.31system 0:08.00elapsed 99%CPU (0avgtext+0avgdata 76516maxresident)k .. This is basically the same speed as with 0.90ubuntu0.10. There is a 12% speed regression when testing in qemu with kvm on a 19.04 host: ... adt-1549534420.log-Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial adt-1549534420.log-Packages that will be upgraded: adt-1549534420.log:6.72user 0.30system 0:07.07elapsed 99%CPU (0avgtext+0avgdata 77812maxresident)k ... vs. .. adt-2.log-Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial adt-2.log-Packages that will be upgraded: adt-2.log:7.64user 0.31system 0:08.00elapsed 99%CPU (0avgtext+0avgdata 76516maxresident)k ... Or a 24% speedup with a smaller set of upgradable packages measured in two 16.04 lxc containers running on the same 19.04 development system: ii unattended-upgrades 0.90ubuntu0.10 all automatic installation of security upgrades # for i in $(seq 5); do time unattended-upgrade --dry-run; done real0m4.326s user0m4.245s sys 0m0.043s real0m4.309s user0m4.239s sys 0m0.070s ... # apt list --upgradable Listing... Done cloud-init/xenial-proposed 18.5-21-g8ee294d5-0ubuntu1~16.04.1 all [upgradable from: 18.4-0ubuntu1~16.04.2] kmod/xenial-proposed 22-1ubuntu5.2 amd64 [upgradable from: 22-1ubuntu5.1] libc-bin/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] libc6/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] libkmod2/xenial-proposed 22-1ubuntu5.2 amd64 [upgradable from: 22-1ubuntu5.1] locales/xenial-proposed 2.23-0ubuntu11 all [upgradable from: 2.23-0ubuntu10] multiarch-support/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] python-apt-common/xenial-proposed 1.1.0~beta1ubuntu0.16.04.3 all [upgradable from: 1.1.0~beta1ubuntu0.16.04.2] python3-apt/xenial-proposed 1.1.0~beta1ubuntu0.16.04.3 amd64 [upgradable from: 1.1.0~beta1ubuntu0.16.04.2] snapd/xenial-proposed 2.37.1 amd64 [upgradable from: 2.34.2] ubuntu-core-launcher/xenial-proposed 2.37.1 amd64 [upgradable from: 2.34.2] unattended-upgrades/xenial-proposed 1.1ubuntu1.18.04.7~16.04.1 all [upgradable from: 0.90ubuntu0.10] # vs. ii unattended-upgrades 1.1ubuntu1.18.04.7~16.04.1 all automatic installation of security upgrades # for i in $(seq 5); do time unattended-upgrade --dry-run; done real0m3.269s user0m3.194s sys 0m0.076s real0m3.277s user0m3.135s sys 0m0.115s ... root@x-uu-ref:~# apt list --upgradable Listing... Done cloud-init/xenial-proposed 18.5-21-g8ee294d5-0ubuntu1~16.04.1 all [upgradable from: 18.4-0ubuntu1~16.04.2] kmod/xenial-proposed 22-1ubuntu5.2 amd64 [upgradable from: 22-1ubuntu5.1] libc-bin/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] libc6/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] libkmod2/xenial-proposed 22-1ubuntu5.2 amd64 [upgradable from: 22-1ubuntu5.1] locales/xenial-proposed 2.23-0ubuntu11 all [upgradable from: 2.23-0ubuntu10] multiarch-support/xenial-proposed 2.23-0ubuntu11 amd64 [upgradable from: 2.23-0ubuntu10] python-apt-common/xenial-proposed 1.1.0~beta1ubuntu0.16.04.3 all [upgradable from: 1.1.0~beta1ubuntu0.16.04.2] snapd/xenial-proposed 2.37.1 amd64 [upgradable from: 2.34.2] ubuntu-core-launcher/xenial-proposed 2.37.1 amd64 [upgradable from: 2.34.2] root@x-uu-ref:~# ** 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
Hello Ernst, 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: New => 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/1396787 Title: checking trust of archives eats a lot of cpu 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] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.4 --- 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 clear cache after failed commits to return from a possibly invalid state (LP: #1779157) * Don't start or gracefully stop upgrade on battery (LP: #1773033) * Skip updates on metered connections (Closes: #855570) (LP: #1781183) * Add debian/tests/upgrade-all-security to install all current security updates. On development releases this tests latest stable, on stable releases it tests the release itself. * Speed up unattended-upgrade (Closes: #892028, #899366) (LP: #1396787) - Adjust candidates only for packages to be possibly installed - Filter out packages cheaper when they are not from allowed origins - Collect autoremovable packages, too, when looking for upgradable ones - Measure time of running with --dry-run in autopkgtests * Skip starting init.d script in debhelper-generated postinst part (LP: #1778800) [ Ivan Kurnosov ] * Fixed is_pkgname_in_blacklist to be side-effect free. (LP: #1781176) Otherwise 'is_pkgname_in_blacklist' mutates the 'pkgs_kept_back' and 'unattended-upgrades' treats the package as a blacklisted candidate -- Balint Reczey Fri, 13 Jul 2018 10:36:23 +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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR=
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
With 1.1ubuntu1.18.04.3 u-u runs in ~3s when no package should be updated but there are upgradable packages in -updates. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/u/unattended-upgrades/20180713_084216_9f8ee@/log.gz : ... Initial blacklisted packages: Initial whitelisted packages: Starting unattended upgrades script Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, o=UbuntuESM,a=bionic No packages found that can be upgraded unattended and no pending auto-removals 2.71user 0.12system 0:02.84elapsed 99%CPU (0avgtext+0avgdata 78924maxresident)k 0inputs+7736outputs (0major+22416minor)pagefaults 0swaps ... The test for 1.1ubuntu1.18.04.4 was most likely run on a slower system where the same run takes ~5s. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/u/unattended-upgrades/20180713_124827_de117@/log.gz : ... Initial blacklisted packages: Initial whitelisted packages: Starting unattended upgrades script Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, o=UbuntuESM,a=bionic No packages found that can be upgraded unattended and no pending auto-removals 5.01user 0.14system 0:05.16elapsed 99%CPU (0avgtext+0avgdata 78992maxresident)k 0inputs+7736outputs (0major+22427minor)pagefaults 0swaps ... ** 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Bionic: Fix Committed Bug description: [Impact] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
Hello Ernst, or anyone else affected, Accepted unattended-upgrades into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source /unattended-upgrades/1.1ubuntu1.18.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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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! ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: New => 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Bionic: Fix Committed Bug description: [Impact] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
** Description changed: + [Impact] + + * Unattended-upgrades consumes tens of seconds or even minutes of CPU + time to verify the origin of the packages + + * Using excessive amount of CPU is unpleasant for desktop/laptop users + and also wastes computation time on servers/cloud instances. + + * Unattended-upgrades' algorithm for checking and adjusting package + origins is redesigned to visit and adjust less packages. + + [Test Case] + + * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. + * Please run autopkgtests and look for the to time results: + ... + All upgrades installed + 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k + 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps + ... + No packages found that can be upgraded unattended and no pending auto-removals + 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k + + + [Regression Potential] + + * Due to algorithm redesign there is a risk that packages from allowed + origins are not upgraded. There were unit tests for testing the + selection of the right packages to upgrade already, but a new + autopkgtest is also introduce to verify u-u's behavior on current real- + life security-updates. + + + [Original bug text] + (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: - TERM=xterm - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=de_DE.UTF-8 - SHELL=/bin/bash + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=de_DE.UTF-8 + SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) -- 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: Fix Released Bug description: [Impact] * Unattended-upgrades consumes tens of seconds or even minutes of CPU time to verify the origin of the packages * Using excessive amount of CPU is unpleasant for desktop/laptop users and also wastes computation time on servers/cloud instances. * Unattended-upgrades' algorithm for checking and adjusting package origins is redesigned to visit and adjust less packages. [Test Case] * The added upgrade-all-security autopkgtest measure the time u-u needs for upgrading security updates on the tested release starting with no security updates applied to the point where all security updates are applied but all packages are left upgradable from -updates. The test also measures the time needed for --dry-run to find no updates to be installed unattended. * Please run autopkgtests and look for the to time results: ... All upgrades installed 44.41user 3.06system 0:48.35elapsed 98%CPU (0avgtext+0avgdata 164872maxresident)k 208inputs+192376outputs (0major+642657minor)pagefaults 0swaps ... No packages found that can be upgraded unattended and no pending auto-removals 2.83user 0.11system 0:02.98elapsed 98%CPU (0avgtext+0avgdata 79308maxresident)k [Regression Potential] * Due to algorithm redesign there is a risk that packages from allowed origins are not upgraded. There were unit tests for testing the selection of the right packages to upgrade already, but a new autopkgtest is also introduce to verify u-u's behavior on current real-life security-updates. [Original bug text] (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a
[Touch-packages] [Bug 1396787] Re: checking trust of archives eats a lot of cpu
This bug was fixed in the package unattended-upgrades - 1.4ubuntu1 --- unattended-upgrades (1.4ubuntu1) cosmic; urgency=medium * Merge from Debian unstable - Remaining changes: - unattended-upgrades: Do not automatically upgrade the development release of Ubuntu unless Unattended-Upgrade::DevRelease is true. - Dropped changes, included in Debian: - Stop rewriting test apt.conf in test_untrusted.py. - Fix test_on_battery on Ubuntu development releases unattended-upgrades (1.4) unstable; urgency=medium * Skip starting init.d script in debhelper-generated postinst part (LP: #1778800) * Use "deb-systemd-invoke start" instead of "systemctl start" in postinst. It is used only in a workaround applied for a Debian bug and for upgrading from pre-bionic versions. * Clear cache when autoremoval is invalid for a package set marked for removal (LP: #1779157) * Clear cache after failed commits to return from a possibly invalid state * Unlock for dpkg operations with apt_pkg.pkgsystem_unlock_inner() when it is available, also stop running when reacquiring the lock fails. Thanks to to Julian Andres Klode for original partial patch * Use fully qualified domain name in email subject. * Send email about all failures and crashes (Closes: #898607) * Add short textual summary of the results in the summary email * Recommend overriding configuration in a separate file. This can be better than changing /etc/apt/apt.conf.d/50unattended-upgrades because package updates don't conflict with local changes this way. * Adjust candidates only for packages to be possibly installed (Closes: #892028, #899366) (LP: #1396787) * Add Unattended-Upgrade::OnlyOnACPower config file example for all distributions * debian/control: Drop redundant Testsuite: autopkgtest field to keep Lintian happy * Bump Standards-Version to 4.1.4 * Add debian/tests/upgrade-all-security to install all current security updates. On development releases this tests latest stable, on stable releases it tests the release itself. * Skip updates on metered connections (Closes: #855570) * Quote shell variables in autopkgtest * Stop u-u early when it should stop later anyway * Measure time for --dry-run and after all updates are installed in autopkgtests * Filter out packages cheaper when they are not from allowed origins * Collect autoremovable packages, too, when looking for upgradable ones -- Balint Reczey Fri, 06 Jul 2018 13:33:29 +0200 ** Changed in: unattended-upgrades (Ubuntu) Status: New => 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: Fix Released Bug description: (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
** Tags added: id-5acfd3863b9f75d6e6f2a6df -- 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: New Bug description: (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
Please note that latest unattended-upgrades contain several speed improvements which are planned to be back-ported to Xenial (and Trusty). -- 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: New Bug description: (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
After digging a bit deeper I found out that that the default configuration of
/etc/apt/apt.conf.d/50unattended-upgrades is exactly the same as I had in my
experiment i.e.
- the ${distro_id}:${distro_codename}-security origin is ENABLED
- the ${distro_id}:${distro_codename}-updates and others origin are DISABLED
The consequences are the following. A fresh install of Ubuntu LTS e.g.
16.04 keeps installing the *-security updates, but not the *-updates
ones. The number of packages with new versions in *-updates repository
keeps growing unless somebody installs them manually. It is a couple of
clicks, but still many people never do it. As the list of upgradable
packages grows, unattended-upgrades get slower and slower to the point
that it may take hours to complete. Effectively, the automatic updates
may no longer work at all depending on how a given system is used. Also
the user experience gets worse with CPU busy executing the unattended-
upgrades script.
All in all, I consider it a serious issue that requires attention.
--
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/1396787
Title:
checking trust of archives eats a lot of cpu
Status in unattended-upgrades package in Ubuntu:
New
Bug description:
(System: Ubuntu 14.04, up to date packages)
I noticed that unattended-upgrades spends a significant amount of time
in phases where it runs at 100% cpu. On a slower machine (core 2 t7200
2GHz) this goes on for minutes rather than seconds. This interferes
with using the machine for other tasks.
Using the --debug option to unattended-upgrades shows that the program
outputs a lot of lines like the following during these 100% cpu
phases:
matching 'a'='trusty-updates' against '
From this output I guess the operation executed is not so complicated
that it should require so much cpu power. ??
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unattended-upgrades 0.82.1ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10
Uname: Linux 3.13.0-40-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
Date: Wed Nov 26 21:53:57 2014
InstallationDate: Installed on 2014-08-28 (90 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64
(20140416.1)
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=de_DE.UTF-8
SHELL=/bin/bash
SourcePackage: unattended-upgrades
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
I've hit the same bug and did some investigation. I profiled the
unattended-upgrade script with python's cProfile and attached the
result.
I've run:
sudo python3 -m cProfile -s time /usr/bin/unattended-upgrade -d -v
on Ubuntu 16.04.3 booted from live cd after uncommenting the
"${distro_id}:${distro_codename}-security"; line in
/etc/apt/apt.conf.d/50unattended-upgrades. Otherwise no packages are selected
for an upgrade and the issue doesn't reproduce.
It turns out that several functions in apt's cache are called millions of
times. I tracked it down to the quadratic nature of the algorithm, which
appears to come from the very initial version of the script:
https://github.com/mvo5/unattended-upgrades/blob/0ec001874ad48300199565f8591818ca75bc5f9f/unattended.py#L47
The check_changes_for_sanity() function loops over all packages in the
cache. This function is called for every package marked for upgrade.
The problem appears on systems with many packages to upgrade (in my case
it was 169). It makes the initial unattended-upgrades run ridiculously
slow. Also, on systems configured to only perform security updates, but
not other updates there's always a considerable list of packages to
upgrade. It renders unattended-upgrades almost unusable on such systems.
I think this is a serious issue and the algorithm should be overhauled.
Doing so many checks seems unnecessary.
** Attachment added: "unatended-upgrade-profile"
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+attachment/5028172/+files/unatended-upgrade-profile
--
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/1396787
Title:
checking trust of archives eats a lot of cpu
Status in unattended-upgrades package in Ubuntu:
New
Bug description:
(System: Ubuntu 14.04, up to date packages)
I noticed that unattended-upgrades spends a significant amount of time
in phases where it runs at 100% cpu. On a slower machine (core 2 t7200
2GHz) this goes on for minutes rather than seconds. This interferes
with using the machine for other tasks.
Using the --debug option to unattended-upgrades shows that the program
outputs a lot of lines like the following during these 100% cpu
phases:
matching 'a'='trusty-updates' against '
From this output I guess the operation executed is not so complicated
that it should require so much cpu power. ??
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unattended-upgrades 0.82.1ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10
Uname: Linux 3.13.0-40-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
Date: Wed Nov 26 21:53:57 2014
InstallationDate: Installed on 2014-08-28 (90 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64
(20140416.1)
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=de_DE.UTF-8
SHELL=/bin/bash
SourcePackage: unattended-upgrades
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
I have same problem on GCP VM(n1-standard-2 and g1-small). a result of dstat indicate that xz and python3 consume most of cpu time on the task. I think this is fatal thing on small core machine. ** Attachment added: "dstat result" https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+attachment/4640632/+files/unattended-upgrades-dstat.txt -- 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: New Bug description: (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against ' From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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 1396787] Re: checking trust of archives eats a lot of cpu
Is there a generic bug or effort for the obtrusiveness of unattended- upgrades? -- 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/1396787 Title: checking trust of archives eats a lot of cpu Status in unattended-upgrades package in Ubuntu: New Bug description: (System: Ubuntu 14.04, up to date packages) I noticed that unattended-upgrades spends a significant amount of time in phases where it runs at 100% cpu. On a slower machine (core 2 t7200 2GHz) this goes on for minutes rather than seconds. This interferes with using the machine for other tasks. Using the --debug option to unattended-upgrades shows that the program outputs a lot of lines like the following during these 100% cpu phases: matching 'a'='trusty-updates' against 'Origin component:'universe' archive:'trusty-updates' origin:'Ubuntu' label:'Ubuntu' site:'de.archive.ubuntu.com' isTrusted:True From this output I guess the operation executed is not so complicated that it should require so much cpu power. ?? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unattended-upgrades 0.82.1ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.5 Architecture: amd64 Date: Wed Nov 26 21:53:57 2014 InstallationDate: Installed on 2014-08-28 (90 days ago) InstallationMedia: Kubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140416.1) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: unattended-upgrades UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1396787/+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
