"The computer needs to restart" dialog constantly eats CPU

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

Bug Description

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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers