upowerd memory usage

jwm-art · 2014-09-01 19:48:47

Same problem here too. The day after installing Arch to replace Debian on partner's laptop :-(

Disabled the service through systemctl but suspect it may get started again as "it will be automatically started by dbus-daemon(1) whenever an application calls into the org.freedesktop.UPower service."

HP Presario V6000 - old laptop, 32bit, uptime < 2hrs.

Last edited by jwm-art (2014-09-01 20:31:03)

ooo · 2014-09-01 21:25:40

you should be able to prevent it from starting via dbus with

systemctl mask upower

however, this will probably cause issues with everything that requires upower to work. At least you'll lose some functionality if nothing else breaks.

~~Does every one of you with this issue happen to be using KDE? I have yet never seen this issue myself running gnome.~~
EDIT. apparently people have issues in gnome as well.

did anyone try either of the patches in that bug report mentioned by Phoenix_alx if they happened to solve the issue?
At least the first one could probably be included in the arch package since it already got merged upstream.

Last edited by ooo (2014-09-01 21:40:40)

jwm-art · 2014-09-05 15:08:22

It's not with my own laptop but my partners. I've set the system up with XFCE. I don't know exactly what's happening when the issue kicks in and memory is consumed, but she usually has LibreOffice open with a couple of documents, nothing large, and Firefox. Last time it happened, after I killed upowerd from the console (the desktop is almost unusable) and went back to the desktop, Firefox was warning about an unresponsive script on a Facebook tab. Killed the script but was still a bit of a struggle to navigate up/down the page.

I've started to wonder if the best thing would be if the upowerd process could be limited. From what I can tell so far it doesn't seem possible to limit a specific process using PAM (/etc/security/limits.conf). I'm going to try limitting memlock for everything to something quite low like 250mb though am a little concerned that may be far too low for some applications (X? FF? LO? etc).

Maybe rather than limiting all users, limit only root, will need to look into how much memory is used by processes owned by root. Haven't tried the patches yet. Hoping they may be applied soon. It's quite a nasty bug.

progandy · 2014-09-05 16:02:11

jwm-art wrote:

I've started to wonder if the best thing would be if the upowerd process could be limited. From what I can tell so far it doesn't seem possible to limit a specific process using PAM (/etc/security/limits.conf). I'm going to try limitting memlock for everything to something quite low like 250mb though am a little concerned that may be far too low for some applications (X? FF? LO? etc).

You can try to set limits in the systemd unit.

       LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=,
       LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=,
       LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=,
       LimitRTPRIO=, LimitRTTIME=
           These settings control various resource limits for executed
           processes. See setrlimit(2) for details. Use the string
           infinity to configure no limit on a specific resource.

Last edited by progandy (2014-09-05 16:02:49)

jwm-art · 2014-09-05 23:07:04

progandy wrote:

You can try to set limits in the systemd unit.

       LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=,
       LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=,
       LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=,
       LimitRTPRIO=, LimitRTTIME=
           These settings control various resource limits for executed
           processes. See setrlimit(2) for details. Use the string
           infinity to configure no limit on a specific resource.

Thanks for that. I've created /etc/systemd/system/upower.service.d/limits.conf:

[Service]
LimitDATA=100000
LimitSTACK=100000
LimitMEMLOCK=100000

Status is shown as:

● upower.service - Daemon for power management
   Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled)
  Drop-In: /etc/systemd/system/upower.service.d
           └─limits.conf
   Active: active (running) since Fri 2014-09-05 23:53:48 BST; 10min ago
     Docs: man:upowerd(8)
 Main PID: 223 (upowerd)
   CGroup: /system.slice/upower.service
           └─223 /usr/lib/upower/upowerd

Sep 05 23:53:51 ArchLappy upowerd[223]: (upowerd:223): UPower-Linux-WARNING **: correcting energy_full (0.000000) using energy_full_design (88.800000)

Will have to wait to see if anything happens...

Last edited by jwm-art (2014-09-05 23:08:18)

maxrd2 · 2014-09-16 19:17:28

I also use Logitech wireless keyboard K520 and mouse M310 and have same issue.

Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver

After memory started leaking I've noticed following message in systemd upower.service status:

Sep 16 21:04:19 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255
Sep 16 21:04:19 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255
Sep 16 21:04:19 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255
Sep 16 21:04:18 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255
Sep 16 21:04:18 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255
Sep 16 21:04:18 beeblebrox kernel: logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index:255

Whole thing started happening recently since the kb/mouse batteries went to <5%

Last edited by maxrd2 (2014-09-16 19:19:00)

jwm-art · 2014-09-16 19:30:43

maxrd2 wrote:

Whole thing started happening recently since the kb/mouse batteries went to <5%

Yes that's how I witnessed it too, when battery is about to completely drain. The laptop screen flashed off and the audio system popped off too, happened a couple of times. Journal mentions hibernation and suspend states. Might explain why the whole system flickers off and back on again (user bashing keys in panic) (maybe more than once?).

However, the system recovered this time, which I believe (but w/o proof) is due to configuring limits for upowerd.

journalctl log: http://pastebin.com/8wkeU3LU

Of which the only standout part I see is:

Sep 09 21:32:22 ArchLappie upowerd[232]: (upowerd:232): GLib-CRITICAL **: Source ID 108 was not found when attempting to remove it

Last edited by jwm-art (2014-09-16 19:32:12)

cra · 2014-11-11 20:20:02

I just want to confirm the problem on my laptop. I use Logitech K360 wireless keyboard as well and experiencing this since the update (haven't updated my system in awhile. However, according to the bug report discussion, the issue with upowerd causing heavy swapping is not connected to Logitech.

ultraviolet · 2014-11-11 22:58:43

update: i have created a package called upower-fixed in the AUR, and since installing it i've noticed MUCH lower resource usage than i've ever had on this device!! i've been running gnome since i got it, and it appears this issue with upower has existed the entire time. it sure is nice to see my cpu temp below 130°F with firefox open! hopefully this package will solve others' issues until either the arch packagers or the freedesktop developers implement the fix.

original post: i also have this problem on my Lenovo ThinkPad Helix (a laptop/tablet with detachable keyboard dock). this device has a battery in the dock as well as the tablet. upowerd generally starts hogging ram (and often cpu as well) once i undock and redock the tablet. it does sometimes happen out of nowhere as well. i am running the newest version of gnome (3.14.1) that's in the regular repos. i do have thermald running, as this machine (i7 cpu in a slim tablet) tends to get quite hot. i haven't otherwise done anything fancy with power management.

here's the output of upower -m --monitor-detail running for less than 10 minutes. as soon as it starts it outputs 48 copies of the following:

[15:42:36.993]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               SMP
  model:                45N1103
  serial:               47
  power supply:         yes
  updated:              Tue 11 Nov 2014 03:42:36 PM MST (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              34.99 Wh
    energy-empty:        0 Wh
    energy-full:         35.73 Wh
    energy-full-design:  42.01 Wh
    energy-rate:         0 W
    voltage:             12.228 V
    percentage:          97%
    capacity:            85.0512%
    technology:          lithium-polymer
    icon-name:          'battery-full-symbolic'
  History (charge):
    1415745753	97.000	discharging
    1415745752	0.000	unknown
  History (rate):
    1415745752	0.000	unknown

it went on to print 12 copies of this:

[15:48:33.095]	device changed:     /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          BAT1
  vendor:               SMP
  model:                45N1101
  serial:               1684
  power supply:         yes
  updated:              Tue 11 Nov 2014 03:48:33 PM MST (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              20.01 Wh
    energy-empty:        0 Wh
    energy-full:         26.92 Wh
    energy-full-design:  28.05 Wh
    energy-rate:         13.893 W
    voltage:             15.369 V
    time to empty:       1.4 hours
    percentage:          74%
    capacity:            95.9715%
    technology:          lithium-polymer
    icon-name:          'battery-full-symbolic'
  History (charge):
    1415746113	74.000	discharging
  History (rate):
    1415746113	13.893	discharging

the copies aren't perfectly identical to each other, but the most significant difference appears to be the timestamps.

i'm going to build upower using the patches suggested above, and will report back if that fixes my issue. (update: it did! see top of post)

Last edited by ultraviolet (2014-11-12 00:12:43)

cra · 2014-11-12 21:03:04

Woohoo! Thanks a lot! I also confirm extremely low resource usage. Will see if it's actually prolongates the battery life

Arch Linux

#26 2014-09-01 19:48:47

Re: upowerd memory usage

#27 2014-09-01 21:25:40

Re: upowerd memory usage

#28 2014-09-05 15:08:22

Re: upowerd memory usage

#29 2014-09-05 16:02:11

Re: upowerd memory usage

#30 2014-09-05 23:07:04

Re: upowerd memory usage

#31 2014-09-16 19:17:28

Re: upowerd memory usage

#32 2014-09-16 19:30:43

Re: upowerd memory usage

#33 2014-11-11 20:20:02

Re: upowerd memory usage

#34 2014-11-11 22:58:43

Re: upowerd memory usage

#35 2014-11-12 21:03:04

Re: upowerd memory usage

Board footer