"The computer needs to restart" dialog constantly eats CPU

Bug #1637180 reported by Giuseppe D'Angelo on 2016-10-27
84
This bug affects 16 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
High
Unassigned
update-manager (Ubuntu)
High
Mathieu Trudel-Lapierre
Artful
High
Adam Conrad
Bionic
High
Mathieu Trudel-Lapierre

Bug Description

[Impact]
Ubuntu users wishing to run updates, potentially with specific combinations of customized theming on their desktop.

[Test case]
1) Run update-manager
2) Apply updates (this should include an update that requires reboot, such as a kernel update, system library (libc?)...
3) Let the "This computer needs to restart" dialog appear.

[Regression potential]
Failure of the "restart" dialog to appear or screen/window corruption when this dialog appears should be investigated as possible regressions. It is also possible that the behavior of the window changes in that its size might not remain static.

---

After installing certain updates (kernel, system libraries, etc.), the "The computer needs to restart" dialog appears periodically, prompting the user to restart the system.

That dialog eats a constant 8-10% of CPU time. That's the issue. (Yes, update-manager is niced to 10, but why consuming *any* CPU at all for showing a static dialog?)

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: update-manager 1:16.04.4
ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
Uname: Linux 4.4.0-38-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Oct 27 14:07:11 2016
ExecutablePath: /usr/bin/update-manager
GsettingsChanges:
 b'com.ubuntu.update-manager' b'show-details' b'true'
 b'com.ubuntu.update-manager' b'window-height' b'766'
 b'com.ubuntu.update-manager' b'first-run' b'false'
 b'com.ubuntu.update-manager' b'window-width' b'939'
 b'com.ubuntu.update-manager' b'launch-time' b'1477544773'
InstallationDate: Installed on 2016-04-22 (188 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
InterpreterPath: /usr/bin/python3.5
PackageArchitecture: all
SourcePackage: update-manager
UpgradeStatus: No upgrade log present (probably fresh install)

Giuseppe D'Angelo (dangelo) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in update-manager (Ubuntu):
status: New → Confirmed

can confirm this bug in 16.04. noticed a few months ago and still present as of now

tags: added: rls-z-incoming
Thomas Waldmann (tw-public) wrote :

Also affects me and is not limited to the "needs to restart" dialogue box.

It also happens for the "computer is up to date" dialogue box shown after applying updates.

Maybe for ANY such dialogue box?

Please fix, this is a real annoyance to having to click on "OK" just to stop the CPU fan spinning all the time.

Changed in update-manager (Ubuntu):
importance: Undecided → High
Changed in hundredpapercuts:
status: New → Confirmed
importance: Undecided → High
tags: added: rls-aa-incoming
removed: rls-z-incoming
Jarno Suni (jarnos) wrote :

I do not notice CPU usage of "computer is up to date" dialogue box. Maybe it is some hardware driver that uses the CPU power?

Thomas Waldmann (tw-public) wrote :

Attached a screenshot with proof.

When I close the dialogue, the cpu usage seen on the screenshot vanishes, so it is definitely the update-manager dialogue causing this.

This is a real annoyance and I am asking myself how many kWh get burned down every day without reason due to this.

Jarno Suni (jarnos) wrote :

Do CPU usage of Xorg and compiz decrease a lot, too, when you close the dialog?

Giuseppe D'Angelo (dangelo) wrote :

Yes. It's likely caused by some broken code calling update() in a loop or something like that. Yet, we're looking at a 30-40% aggregated between the app, X and compiz.

Jarno Suni (jarnos) wrote :

Could you try disabling compiz, if it has an effect?

Giuseppe D'Angelo (dangelo) wrote :

In that case, X usage goes down, and of course compiz isn't there any more, but the dialog is still eating CPU. I don't know anything about GTK nor python, so I don't really know how to track this down, otherwise I would've already done that...

Thomas Waldmann (tw-public) wrote :

I found out something interesting right now:

- when the update manager dialogue box is the selected window, it does not suck a lot of cpu

- but when you select something else (an icon, another window, does not matter), cpu usage of update-manager, compiz and xorg jumps upwards (see screenshot in my last post).

This is reproducible: cpu goes up and down when selecting one or the other.

Jarno Suni (jarnos) wrote :

Another oddity with Software Updater is Bug #1332543;at least in Trusty it may still appear.

Brian Murray (brian-murray) wrote :

I tried recreating this on zesty with update-manager version 1:17.04.3 and I did not notice update-manager using CPU. One other difference from the original reporter is that I am using an Intel graphics adapter. I'll keep testing though.

Steve Langasek (vorlon) on 2017-06-22
Changed in update-manager (Ubuntu Artful):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
assignee: Mathieu Trudel-Lapierre (cyphermox) → Adam Conrad (adconrad)
tags: removed: rls-aa-incoming
Thomas Waldmann (tw-public) wrote :

@brian I also have intel gfx (haswell generation integrated gfx) in my laptop and this issue is happening about every day for me (each time update-manager waits for my final click - which is kind of superfluous anyway for cases where updates worked flawlessly).

So I am wondering whether this gets a high enough priority considering this was reported over half a year ago.

I am currently on a conference, so running on battery power frequently and not having a power socket available as often / as long as needed.

Noticing (this time not due to fan noise [too loud here to notice], but due to hot air coming out of the fan) that it needlessly burned battery power again is so annoying. :-(

Also, I am wondering if this will ever get fixed in 16.04.x or just in the latest / upcoming releases?

Brian Murray (brian-murray) wrote :

Thomas if you could get a stacktrace of update-manager so we can figure out what it is doing that would be helpful. If we can fix it then yes we would fix it in stable releases, including Ubuntu 16.04.

Brian Murray (brian-murray) wrote :

I meant backtrace not stacktrace.

Giuseppe D'Angelo (dangelo) wrote :

Hi Brian,

do you know some way to get a good backtrace for your purpose? Note that this is 100% reproducible, just run update manager, and even if it tells you that the system is up to date, switch window focus to somewhere else to trigger the 8-10% CPU usage.

A quick gdb -p PID and bt doesn't convey much information, the app is stuck in GTK's event loop:

(gdb) bt
#0 0x00007f31edfd170d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f31ec62338c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f31ec623712 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f31e3f33395 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4 0x00007f31ec3d6e40 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#5 0x00007f31ec3d68ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#6 0x00007f31ecdc58fc in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
#7 0x00007f31ecdc73e8 in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
#8 0x00000000005b7167 in PyObject_Call ()
#9 0x0000000000528d06 in PyEval_EvalFrameEx ()
#10 0x000000000052d2e3 in ?? ()
#11 0x000000000052dfdf in PyEval_EvalCode ()
#12 0x00000000005fd2c2 in ?? ()
#13 0x00000000005ff76a in PyRun_FileExFlags ()
#14 0x00000000005ff95c in PyRun_SimpleFileExFlags ()
#15 0x000000000063e7d6 in Py_Main ()
#16 0x00000000004cfe41 in main ()

Also when this happens strace shows just an endless and constant stream of poll() wakeups over the X11 socket descriptor:

poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 498) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"A\0Db\374\23`\4\3\0\202\0\f\0`\4\0P8\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, 0x7fffa8436e80, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x7fffa8436d30, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x7fffa8436e60, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 498) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"#\203|b\32\0\0\0\6\0\2\0\340\330\333\10\0\0\0\0\366\0\0\0\7\0`\4\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 136
recvmsg(3, 0x7fffa8436e80, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x7fffa8436d30, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x7fffa8436e60, 0) = -1 EAGAIN (Resource temporarily unavailable)

This stops as soon as the window gets focused.

Thomas Waldmann (tw-public) wrote :

this is the easiest way to fix the issue (not perfect though, dialog box looks slightly different afterwards):

--- UpdateManager.py.orig 2017-07-20 22:23:11.643707331 +0200
+++ UpdateManager.py 2017-07-20 22:24:03.048405983 +0200
@@ -88,9 +88,10 @@
         self.set_icon_name("system-software-update")
         self.set_position(Gtk.WindowPosition.CENTER)

- # Keep window at a constant size
- ctx = self.get_style_context()
- ctx.connect("changed", lambda ctx: self.resize_to_standard_width())
+ # commented as this causes high cpu load
+ ## Keep window at a constant size
+ #ctx = self.get_style_context()
+ #ctx.connect("changed", lambda ctx: self.resize_to_standard_width())

         # Signals
         self.connect("delete-event", self._on_close)

I suspect that the resize_to_standard_width method causes a changed signal, which causes it being called again (and again and again ...).

Guess this should be pretty easy to fix for someone who has a clue about gtk (= not me).

Sebastien Bacher (seb128) wrote :

some guessing work/suggestion here, resize_to_standard_width() does

        ctx = self.get_style_context()
        size = ctx.get_property("font-size", Gtk.StateFlags.NORMAL)

that's likely to create a "changed" event and trigger the loop

the usual way to fix those is to call
GObject.signal_handler_block() before those lines
and
GObject.signal_handler_unblock()
after the lines

you just need to get the right handler in the function to do that

tags: added: rls-aa-notfixing rls-bb-incoming
tags: added: id-597a83347da07175ddd93722
Thomas Waldmann (tw-public) wrote :

This issue has priority "high" and is now over one year old.

A fix is known (see my post above) - I apply this diff each time a update-manager update overwrites the patched version on my laptop and it works ok for me since I wrote it.

So, can we have this finally fixed, please? In all supported releases?

As long as you can't come up with a cosmetically nicer fix than mine, how about just applying mine to fix the big problem and do the cosmetics later?

Steve Langasek (vorlon) on 2017-11-09
tags: removed: rls-bb-incoming
tags: added: rls-bb-notfixing
Changed in update-manager (Ubuntu):
assignee: Adam Conrad (adconrad) → Mathieu Trudel-Lapierre (cyphermox)
Changed in update-manager (Ubuntu Bionic):
assignee: Adam Conrad (adconrad) → Mathieu Trudel-Lapierre (cyphermox)
Changed in update-manager (Ubuntu):
status: Confirmed → In Progress
Changed in update-manager (Ubuntu Bionic):
status: Confirmed → In Progress
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:18.10.1

---------------
update-manager (1:18.10.1) cosmic; urgency=medium

  * Block style context changed signal while enforcing the main window's
    constant size. Thanks to Thomas Waldmann and Sebastien Bacher for the
    initial analysis of this bug. (LP: #1637180)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 28 May 2018 10:03:52 -0400

Changed in update-manager (Ubuntu):
status: In Progress → Fix Released

Hello Giuseppe, or anyone else affected,

Accepted update-manager into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:18.04.11.1 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 update-manager (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
Changed in hundredpapercuts:
status: Confirmed → Fix Released
Adam Conrad (adconrad) wrote :

Hello Giuseppe, or anyone else affected,

Accepted update-manager into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:18.04.11.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!

Giuseppe D'Angelo (dangelo) wrote :

Hi,

Unfortunately I'm still on 16.04, waiting for 18.04.1 to upgrade, so I can't test the proposed right now...

Thanks for all the effort at fixing this annoyance!

Verification-done with update-manager/1:18.04.11.2 on bionic:

Verified that the restart CPU does not show 100% CPU usage, and it does show without crashing update-manager. AFAICT this is fixed correctly.

tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:18.04.11.2

---------------
update-manager (1:18.04.11.2) bionic; urgency=medium

  * Fix my embarassing typo that makes update-manager report crashes, when
    instanciating the "reboot" dialog and mangling signals. (LP: #1774131)

update-manager (1:18.04.11.1) bionic; urgency=medium

  * Block style context changed signal while enforcing the main window's
    constant size. Thanks to Thomas Waldmann and Sebastien Bacher for the
    initial analysis of this bug. (LP: #1637180)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 08 Jun 2018 11:50:10 -0700

Changed in update-manager (Ubuntu Bionic):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for update-manager has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hello Giuseppe, or anyone else affected,

Accepted update-manager into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:17.10.15 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-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in update-manager (Ubuntu Artful):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-artful
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers