"The computer needs to restart" dialog constantly eats CPU

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

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

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.

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?

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.

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

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.

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

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

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.

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

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.

@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?

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.

I meant backtrace not stacktrace.

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.

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

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

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?

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

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!

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!

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.

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

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!

Verification-done on artful, using update-manager 1:17.10.15:

Verified that the application does not take 100% CPU while waiting for input at the "computer needs restart" dialog; and the expected code changes are applied on the python modules on disk. Applying updates completed without issues.

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

---------------
update-manager (1:17.10.15) artful; 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> Tue, 19 Jun 2018 09:55:31 -0400