Bug 1427621 - Regression - upowerd/gnome-power-statistics devastated by lack of /proc/timer_stats; high CPU, memory consumption
Summary: Regression - upowerd/gnome-power-statistics devastated by lack of /proc/timer...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: upower
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-28 18:01 UTC by Saurav Sengupta
Modified: 2017-12-12 10:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 10:04:32 UTC


Attachments (Terms of Use)
GNOME Power shows UPower error (29.45 KB, image/png)
2017-02-28 18:01 UTC, Saurav Sengupta
no flags Details
GNOME System Monitor showing resource usage (89.67 KB, image/png)
2017-02-28 18:01 UTC, Saurav Sengupta
no flags Details
GNOME System Monitor showing upowerd CPU usage (18.63 KB, image/png)
2017-02-28 18:02 UTC, Saurav Sengupta
no flags Details
GNOME Power shows UPower error (33.74 KB, image/png)
2017-03-06 03:38 UTC, Daibhidh
no flags Details

Description Saurav Sengupta 2017-02-28 18:01:05 UTC
Created attachment 1258467 [details]
GNOME Power shows UPower error

Description of problem:
Since the upgrade to kernel 4.9.11-200 on Fedora 25, running gnome-power-statistics causes upowerd to go wild and consume a lot of CPU and memory resources. This seems to be due to a missing /proc/timer_stats. The situation is exactly the same as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298.

Version-Release number of selected component (if applicable):
kernel 4.9.11-200, 4.9.12-200
upower 0.99.4-2

How reproducible:
Always

Steps to Reproduce:
1. Run one of the aforementioned kernels.
2. Run gnome-power-statistics

Actual results:
gnome-power-statistics hangs and upowerd consumes a lot of CPU resources. Memory usage keeps going up.

Expected results:
This should not happen. If upowerd is searching in vain for /proc/timer_stats, it should not do so after it fails to find it.

Additional info:

Comment 1 Saurav Sengupta 2017-02-28 18:01:46 UTC
Created attachment 1258468 [details]
GNOME System Monitor showing resource usage

Comment 2 Saurav Sengupta 2017-02-28 18:02:24 UTC
Created attachment 1258469 [details]
GNOME System Monitor showing upowerd CPU usage

Comment 3 Saurav Sengupta 2017-02-28 19:34:31 UTC
The exact situation is as posted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298#40. With kernel 4.8.6-300 /proc/timer_stats is present and this problem does not occur.

Comment 4 Daibhidh 2017-03-06 03:38:01 UTC
Created attachment 1260256 [details]
GNOME Power shows UPower error

There is no /proc/timer_stats

Comment 5 Christian Stadelmann 2017-04-09 09:26:55 UTC
I've created upstream bug reports:

upower: https://bugs.freedesktop.org/show_bug.cgi?id=100626 explaining why /proc/timer_stats is gone

gnome-power-manager/gnome-power-statistics: https://bugzilla.gnome.org/show_bug.cgi?id=781088

Comment 6 jylo06g 2017-04-18 15:15:17 UTC
I can't believe this bug existed as far back to 2012
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298

Comment 7 skierpage 2017-05-27 09:11:33 UTC
This happened to me on Fedora 25 using *KDE*, i.e. not Gnome System Monitor or gnome-power-statistics. I did run all 93 KDE system setting modules (`kcmshell5 --list`) to investigate another bug, and that includes various power management monitors like kcm_energyinfo and powerdevilprofilesconfig. Around the same time upowerd started consuming 30-50% CPU, and `journalctl -xu upower` had 3000 lines like
  May 26 13:35:34 xx upowerd[1266]: failed to get data: Failed to open file '/proc/timer_stats': No such file or directory

Workaround: `systemctl restart upower`

Comment 8 Daibhidh 2017-05-31 01:51:33 UTC
The above workaround does not fix anything for me. GNOME Power still shows UPower error.

    GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats

with gnome-power-statistics hanging and the following software consuming large amounts of CPU resources: upowerd (around 30%), dbus-daemon (around 16%) and gnome-power-statistics (around 14%).

There is no /proc/timer_stats.

Comment 9 Daibhidh 2017-05-31 02:42:13 UTC
(In reply to Daibhidh from comment #8)
> The above workaround does not fix anything for me. GNOME Power still shows
> UPower error.
> 
>     GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats
> 
> with gnome-power-statistics hanging and the following software consuming
> large amounts of CPU resources: upowerd (around 30%), dbus-daemon (around
> 16%) and gnome-power-statistics (around 14%).
> 
> There is no /proc/timer_stats.

O.K., "systemctl restart upower" is to fix the ensuing upowerd problem. I just optimistically jumped to the wrong conclusion - that it would fix the gnome-power-statistics problem (silly me!) - until I got my brain into gear, and then hopefully the right conclusion :-).

I'm surprised hardly anyone else has added to these reports - does no-one use
gnome-power-statistics nowadays?

Comment 10 Christian Stadelmann 2017-05-31 07:41:20 UTC
(In reply to Daibhidh from comment #9)
> I'm surprised hardly anyone else has added to these reports - does no-one use
> gnome-power-statistics nowadays?

I don't think so. It's not a day-to-day end user application. If it is being used, then just once (where it fails) and then users forget about it. Except for the few users who do report bugs.

Comment 11 Arnaud 2017-06-13 18:01:08 UTC
it does it

Comment 12 Arnaud 2017-06-13 18:02:00 UTC
sorry... it also affects f26 mate

Comment 13 Saurav Sengupta 2017-07-18 06:03:10 UTC
(In reply to Christian Stadelmann from comment #10)
> (In reply to Daibhidh from comment #9)
> > I'm surprised hardly anyone else has added to these reports - does no-one use
> > gnome-power-statistics nowadays?
> 
> I don't think so. It's not a day-to-day end user application. If it is being
> used, then just once (where it fails) and then users forget about it. Except
> for the few users who do report bugs.

That may be so, but KDE has much more useful information on power usage than GNOME Power. KInfocentre - Energy Information shows which programs are using how much battery power, and that is both extremely useful for laptops and other mobile devices - if the battery starts getting drained, I can see at a glance what is causing the problem, and, to my knowledge the only set-up that provides this information in a user-friendly way as is. Although it does not go haywire like GNOME Power without /proc/timer_stats and appears to deal with the situation more resiliently (on my system upowerd subsequently takes up not more than 1% CPU, and all cores and memory function normally without anything going out of hand), it is still unable to show this energy usage information. This information is one of the several things that set KDE apart with respect to the user having knowledge of what's going on in the system.

From the link in comment #5 I gather that /proc/timer_stats has always been optional, but given that practically everything depends on it in the current state of things, I think that it would be more difficult to reprogram all the existing user-end infrastructure than it would be to restore timer_stats, at least until developers of the former are given some time to rewire their stuff. It's just my personal opinion, but I think that API/ABI changes should be introduced gradually and with some grace period allowed to downstream developers.

Comment 14 srh 2017-07-24 06:18:26 UTC
I also see this problem using gnome-power-statistics in F25. upowerd uses 100% cpu after gnome-power-statistics is run a second or third time, and switching to the 'Processor' tab. Its shows:
Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats

'systemctl status upower' shows:
upowerd[11778]: failed to get data: Failed to open file '/proc/timer_stats': No such file or directory

I have to force close gnome-power-statistics, and run 'systemctl restart upower' to get back to normal cpu usage. Running gnome-power-statistics and switching to 'Processor' tab causes the same problem again. 


Ok, this was supposedly fixed on 2017-04-23 in

https://bugs.freedesktop.org/show_bug.cgi?id=100626
upower relies on /proc/timer_stats, which was always optional and has been removed from recent kernels; busy loop and memory leak

https://cgit.freedesktop.org/upower/commit/?id=798588a480eaae50368bed75fc78f8314523b2a3
Do not spin in a loop when /proc/timer_stats cannot be written

Can this fix please be pushed out to F25 and F26. Thanks.

Comment 15 srh 2017-07-26 10:22:51 UTC
upower-0.99.5-1.fc25 has been pushed to F25 testing repo, and it fixes the 100% cpu issue. Cpu used by upowerd is now almost zero. Thanks!!

But when running gnome-power-statistics and switching to the 'Processor' tab, it still shows:
Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats

and no information is listed down the 'Wakeups' page. However, I assume that is now a gnome-power-statistics problem/bug, where gnome-power-statistics needs to now find the info from somewhere else??

Comment 16 Arnaud 2017-07-26 10:33:41 UTC
with upower-0.99.5-1.fc26.x86_64, I still see upower trying to kill my processor,
if I start mate-power-statistics

Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type
[etc. 1'000'000 lines]

Comment 17 Daibhidh 2017-07-28 01:42:40 UTC
Just to confirm that, for me, following the upgrade to upower-0.99.5-1.fc26,
when running gnome-power-statistics and switching to the 'Processor' tab,
the upowerd, dbus-daemon and gnome-power-statistics processes
do not run away any more, so there is no more high CPU and memory consumption.
Thank you for fixing that :-).

And also to confirm that when running gnome-power-statistics and switching to the 'Processor' tab, it still shows, of course:
Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats
and no information is listed on the Wakeups page.

Comment 18 Saurav Sengupta 2017-07-28 05:16:52 UTC
I think that the "cannot enable timerstats"/failure to get data part will remain because it seems to read from /proc/timer_stats. Now, however, even Ubuntu (17.10) seems to have dropped timer_stats, so that the energy information previously available in KDE is also gone, although KInfocentre still doesn't show an error message as GNOME Power does - see comment #13.

Comment 19 Dominik 'Rathann' Mierzejewski 2017-10-12 08:47:40 UTC
(In reply to Heldwin from comment #12)
> sorry... it also affects f26 mate

Same here,
mate-power-manager-1.18.0-2.fc26.x86_64

Shall I open a separate bug against mate-power-manager for using an obsolete API? Is there a replacement they can use?

Comment 20 Christian Stadelmann 2017-10-12 09:58:30 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #19)
> (In reply to Heldwin from comment #12)
> > sorry... it also affects f26 mate
> 
> Same here,
> mate-power-manager-1.18.0-2.fc26.x86_64
> 
> Shall I open a separate bug against mate-power-manager for using an obsolete
> API? Is there a replacement they can use?

Yes, please report a bug against mate-power-manager. You might want to report it upstream so that other Linux distributions will also get the fixes.

As far as I know there is no replacement. The original feature has been removed from the kernel for security reasons and will not be added back again. See comment #5 for details.

Comment 21 Fedora End Of Life 2017-11-16 19:14:30 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 22 Fedora End Of Life 2017-12-12 10:04:32 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.