Bug#919046: unattended-upgrades: Uses 25% of CPU time even when offline
Hi Gábor,
On Sat, Jan 12, 2019, 15:57 Braun Gábor Package: unattended-upgrades
> Version: 1.9
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> On my laptop the fan started running unexpectedly. Starting KDE's
> systemmonitor
> it showed unattended-upgrades using 25% of CPU. The laptop was offline at
> ths time.
>
>* What outcome did you expect instead?
>
> In my opinion, unattended-ugrades should use minimal system resources as a
> background process.
>
I agree, there is ongoing work on optimizing CPU usage.
I have also doubts that it can do anything useful on an offline system.
>
There is a plan to support offline upgrades and it is already possible to
upgrade most packages offline if they are already downloaded thus I don't
plan making u-u stop early when the system is offline. See: https://
github.com/mvo5/unattended-upgrades/issues/155
Cheers,
Balint
> Best wishes,
>
> Gábor
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
> LANGUAGE=hu:en_US:de (charmap=UTF-8)
> Shell: /bin/sh linked to /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 lsb-base 10.2018112800
> ii lsb-release10.2018112800
> ii python33.7.1-2
> ii python3-apt1.7.0
> ii python3-dbus 1.2.8-2+b2
> ii python3-distro-info0.20
> ii ucf3.0038
> ii xz-utils 5.2.2-1.3
>
> Versions of packages unattended-upgrades recommends:
> ii anacron 2.3-27
> ii cron [cron-daemon] 3.0pl1-130
> ii systemd-sysv239-15
>
> Versions of packages unattended-upgrades suggests:
> ii bsd-mailx 8.1.2-0.20180807cvs-1
> ii dma [mail-transport-agent] 0.11-1+b1
> ii needrestart 3.3-2
> ii powermgmt-base 1.33
> ii python3-gi 3.30.4-1
>
> -- debconf information:
> unattended-upgrades/enable_auto_updates: true
> unattended-upgrades/origins_pattern:
> "origin=Debian,codename=${distro_codename},label=Debian-Security";
>
Bug#898216: unattended-upgrades: flaky autopkgtest
On Fri, Sep 21, 2018, 21:00 Paul Gevers wrote: > Hi Balint, > > On 05-09-18 22:13, Paul Gevers wrote: > > On Fri, 6 Jul 2018 14:06:32 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?= > > wrote: > >> I monitored the runs for some time and the test does not seem to be > >> flaky in unstable. Since I added a new test with debootstrap I keep > >> monitoring it and it shows to be flaky I may add retries somewhere. > > > > September 2, 2018: > > > https://ci.debian.net/data/autopkgtest/testing/amd64/u/unattended-upgrades/926140/log.gz > > > > In unstable August 23, 2018: > > > https://ci.debian.net/data/autopkgtest/unstable/amd64/u/unattended-upgrades/871383/log.gz > > unattended-upgrades is failing now in testing with python-apt/1.7.0~rc1 > twice in a row. Can you check that this is a real regression or again > just unattended-upgrades being flaky? > It is, I have the fix waiting for review on GitHub. Cheers, Balint > Paul > >
Bug#747012: Regression test failures on powerpc, s390x and sparc
2014.07.15. 23:04, Stephen Kitt sk...@debian.org ezt írta: On Sat, 12 Jul 2014 14:20:22 +0200, Bjorn Reese bre...@mail1.stofanet.dk wrote: [...] Applied. Thanks! Great! Bjorn, do your plan making a new release anytime soon? It fixes it on all three platforms I'm looking at here: PowerPC, SPARC and S390x. Great. I have created a fix that marks PowerPC, SPARC, and S390x as using double-double, and then use this to conditionally compile either of the two versions above. However, I have not tested them on the different platforms. I've tested the current git tip on ARM (little-endian), x86_64, PowerPC, SPARC and S390x, and the tests pass everywhere. Thanks! I will backport the fixes unless these will be a new official release. Cheers, Balint OK, so perhaps in this case the regression failure usb to be expected, since the test is specifically designed to test long doubles... Would it be useful to distinguish full long double support from double-double support? Yes, I think so. The regression test is about a little-used trio extension (the R flag for rounding) anyways, so it does not look important. I am disabled it in git. Thanks! Regards, Stephen -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Ctrio-talk mailing list ctrio-t...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ctrio-talk
Bug#579297: Re: [pkg-wpa-devel] Bug#579297: wpasupplicant: Recompiling with gnutls fixes (or workarounds) the problem
2012/11/13 Balint Reczey rbal...@gmail.com: ... In an eduroam environment (which is basically WPA-Enterprise), I can confirm disconnects without the possibility to reconnect when using wpa_supplicant wit network-manager. Killing and restarting wpa_supplicant allows a temporary reconnect. Please try to collect the capture file using wireshark about the issue happening and post the releavant part. It seems there are multiple issues merged together. This is http://w1.fi/bugz/show_bug.cgi?id=447 respectively http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668612 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561081 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574714 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579297 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667706 When researching the problem, I found this posting: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/429370/comments/19 It states that the problem may be actually an openssl bug which lets the rekeying process fail permamently, and recommended recompiling with gnutls instead of openssl. I did this: […] The problem with this suggestion and the according patch, is that it switches from one (known) set of bugs to another (unknown) one. While linking to gnutls is supported upstream, none of the major distributions (not even Ubuntu) actually does so, which makes it pretty much untested in practice. Even if we wanted to switch to gnutls, doing so simply isn't possible at this stage of Debian's release process and in freeze*. *) However technically speaking, we can't switch to gnutls anytime soon, because gnutls doesn't provide an udeb, which is needed for using wpa_supplicant by the Debian installer (d-i). While your package build against gnutls succeeded, you have most likely ended with an unsatisfiable (in the d-i/ udeb context) dependency on libgnutls26-udeb for wpasupplicant-udeb_*.udeb (dpkg-gensymbols employs very crude heuristics to construct the dependencies for udeb packages without actually having access to a udeb context). […] and have been testing the modified package for about a month now, the frequent disconnects have completely disappeared. The right place for a real fix would probably be openssl, but the problem does not seem to be addressed or sufficiently researched there, so the workaround by using gnutls instead of openssl gnutls seems to be the best option for now. […] At this moment it is not obvious to me if wpa_supplicant is broken, or if some popular commercial wlan installations used for eduroam institutions are to blame. While, given the ubiquity and prevalence of this issue in academic environments, it might be possible that wpa_supplicant may need to work around the problem, however this would best be fixed at wpa_supplicant's upstream. Unfortunately none of the current wpa maintainers for Debian has access to an affected wlan setup in order to try to reproduce the problem, nor has enough information to recreate an affected EAP/ PAP setup for debugging, which significantly reduces our abilities to help. Therefore it's probably best to engage with wpa_supplicant upstream to get this fixed once and for all. Regards Stefan Lippers-Hollmann Hi, Please see the attached patch fixing the problem while not breaking other use cases. The fix turns off listing the SessionTicket TLS extension in every second hello packet allowing broken servers to accept the connection. Log: 1 0.0 Apple_ee:ee:ee - Procurve_aa:aa:aa EAP 30 Response, Identity 3 0.060381000 Procurve_aa:aa:aa - Apple_ee:ee:ee EAP 60 Request, Protected EAP (EAP-PEAP) 4 0.060918000 Apple_ee:ee:ee - Procurve_aa:aa:aa SSL 249 Client Hello 5 0.111778000 Procurve_aa:aa:aa - Apple_ee:ee:ee TLSv1 60 Alert (Level: Fatal, Description: Bad Certificate) 6 0.11214 Apple_ee:ee:ee - Procurve_aa:aa:aa EAP 24 Response, Protected EAP (EAP-PEAP) 7 0.163244000 Procurve_aa:aa:aa - Apple_ee:ee:ee EAP 60 Failure 8 0.74535 Procurve_aa:aa:ab - Apple_ee:ee:ee EAP 60 Request, Identity 9 0.745615000 Apple_ee:ee:ee - Procurve_aa:aa:ab EAP 30 Response, Identity 10 0.809622000 Procurve_aa:aa:ab - Apple_ee:ee:ee EAP 60 Request, Protected EAP (EAP-PEAP) 11 0.810101000 Apple_ee:ee:ee - Procurve_aa:aa:ab SSL 245 Client Hello 12 0.901729000 Procurve_aa:aa:ab - Apple_ee:ee:ee EAP 918 Request, Protected EAP (EAP-PEAP) 13 0.901942000 Apple_ee:ee:ee - Procurve_aa:aa:ab EAP 24 Response, Protected EAP (EAP-PEAP) As you can see the first hello is longer due to the extension and has been rejected by the buggy server. The second connection attempt has not listed the extension and has been accepted by the buggy server - which happens to run on a different host. Please forward the patch upstream as well, I did not want to register to their bugzilla for
