Package: upower Version: 0.9.17-1 Severity: important I noticed upowerd using ~1.3 gigs of resident memory and burning most of a cpu; strace proved to show that it was attempting to open /proc/timer_stats over and over, failing, and logging an error about it (which was redirected to /dev/null, so that itself didn't have much impact). Enabling CONFIG_TIMER_STATS requires a kernel w/debugging, which the kernel I was running lacked, but regardless, upowerd shouldn't try over and over again to mess with /proc/timer_stats if it fails the first time. It isn't like that's a condition that will ever change during the lifetime of the process.
I haven't confirmed that running upowerd w/o CONFIG_TIMER_STATS=y is what causes the memory leak yet, but I'd bet it's almost certainly what causes the majority of the cpu usage. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
