Control: tags -1 wontfix
Control: severity -1 wishlist

Hi Antoine,

Antoine Beaupre <[email protected]> ezt írta (időpont: 2018. okt.
24., Sze, 16:24):
>
> 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?

IMO no. Unattended-upgrades perform the upgrades in minimal steps to
allow gracefully stopping after each minimal package set and also for
minimizing the breakage when one package fails to upgrade.
Installing each set is a separate full transaction and it is safer to
running all hooks because even unattended-upgrades can crash during
installing a minimal step and may not be able to run the deferred
hooks later.
The main point of unattended-upgrades in ensuring that security
upgrades are applied in stable and in stable we can safely assume that
there are way less upgrades to install in each u-u run than in
testing.

I don't want to change the behavior in testing or in unstable either
because packages are more likely to break in testing and unstable and
we would also lose test coverage while preparing each stable release.

>
> 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.

This is clearly a needrestart bug, not something u-u can solve.

IMO if hooks are slow they need to be sped up.

Cheers,
Balint

Reply via email to