Package: unattended-upgrades Version: 1.6 Severity: normal Extra features like apt-listbugs or needrestart can make unattended-upgrades needlessly slow, especially in case of poor network conditions (in the case of apt-listbugs).
This morning, my IPv6 connexion was down and this meant that apt-listbugs would hang for a few minutes every time it would be called. In a normal `apt upgrade` run, this wouldn't be much of a problem: just take the hit once and we go along with the rest of the upgrade. But now my daily `testing` updates have been running for 45 minutes. During that time, it managed to upgrade only a dozen packages, and nothing fancy: $ sed -n '/2018-10-24/,$p' < /var/log/unattended-upgrades/unattended-upgrades-dpkg.log | grep Dépaquetage Dépaquetage de debhelper (11.4.1) sur (11.3.5) ... Dépaquetage de geoclue-2.0 (2.5.1-1) sur (2.5.0-2) ... Dépaquetage de gir1.2-geoclue-2.0:amd64 (2.5.1-1) sur (2.5.0-2) ... Dépaquetage de gir1.2-rest-0.7 (0.8.1-1) sur (0.8.0-2) ... Dépaquetage de hdparm (9.57+ds-1) sur (9.56+ds-2) ... Dépaquetage de libgeoclue-2-0:amd64 (2.5.1-1) sur (2.5.0-2) ... Dépaquetage de libllvm6.0:amd64 (1:6.0.1-9.1) sur (1:6.0.1-9) ... Dépaquetage de libmail-message-perl (3.007-1) sur (3.006-1) ... Dépaquetage de libmail-transport-perl (3.003-1) sur (3.002-1) ... Dépaquetage de libopenmpt-modplug1:amd64 (0.3.13-1) sur (0.3.12-1) ... Dépaquetage de libopenmpt0:amd64 (0.3.13-1) sur (0.3.12-1) ... Dépaquetage de librest-0.7-0:amd64 (0.8.1-1) sur (0.8.0-2) ... Dépaquetage de libsocket6-perl (0.29-1) sur (0.28-1) ... We could argue this is a bug in apt-listbugs - it should give us "happy eyeballs" and fallback correctly to IPv4 in case of network outages. But this is still slower than it should be. And then there's `needrestart`, which can also take a significant amount of CPU,as it inspects the whole process trees and forests of Perl libraries, which is ran after each invocation, when it could be ran only once. Shouldn't we run all those hooks only once? One time before unattended-upgrade starts, and one time when it finishes, for all packages? I mean even now than I fixed the network, the upgrade seems excruciatingly slow. Now the culprit is needrestart which adds a good 30 seconds to each package upgrade. I do not, as far as I can tell, run in "minimal steps" mode: // Split the upgrade into the smallest possible chunks so that // they can be interrupted with SIGTERM. This makes the upgrade // a bit slower but it has the benefit that shutdown while a upgrade // is running is possible (with a small delay) //Unattended-Upgrade::MinimalSteps "false"; Although it's a little unclear to me if the above documents the value, so I'm unsure if MinimalSteps is enabled here. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.69 ii gir1.2-glib-2.0 1.58.0-1 ii lsb-base 9.20170808 ii lsb-release 9.20170808 ii powermgmt-base 1.33 ii python3 3.6.6-1 ii python3-apt 1.7.0 ii python3-gi 3.30.1-1 ii ucf 3.0038 ii xz-utils 5.2.2-1.3 Versions of packages unattended-upgrades recommends: ii anacron 2.3-24 ii cron [cron-daemon] 3.0pl1-130 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20180807cvs-1 ii needrestart 3.3-1 ii postfix [mail-transport-agent] 3.3.0-1+b1 -- debconf-show failed
