policykit cause high dbus-daemon cpu usage

Never mind, it seems it has nothing to do with resuming from suspend. This morning it started doing it about half an hour after starting my laptop.

It's too soon to call but I think it had something to do with my messing with some more esoteric settings for nautilus in gconf. I've reset nautilus and hopefully it works itself out.

-Josh

How did that go?

Often high D-Bus CPU usage is actually due to a process spamming the bus with a large number of messages

Still does it, mostly after resume from suspend but sometimes on its own.

I asked on the forums here http://ubuntuforums.org/showthread.php?t=1275316 but now response so far. This thread includes a dump from dbus-monitor --system (attached here too) for a few seconds which shows large amounts of spam apparently coming from the daemon itself.

Still, it only occurs when using GNOME; LXDE does not cause this particular issue.

On Sat, 2009-10-10 at 22:55 +0000, Joshua Gardner wrote:

> I asked on the forums here
> http://ubuntuforums.org/showthread.php?t=1275316 but now response so
> far. This thread includes a dump from dbus-monitor --system (attached
> here too) for a few seconds which shows large amounts of spam apparently
> coming from the daemon itself.
>
This implies that something is repeatedly reconnecting to the bus.

Scott
--
Scott James Remnant
<email address hidden>

How do I find out what is doing that, then?

I found out what is causing dbus to go nuts. It's part of policykit, /usr/lib/policykit/polkit-read-auth-helper.

I found out by simple killing processes and daemons one at a time until dbus stopped freaking out. I guess I'll go talk to the policykit guys now. Is there some way to transfer this bug to policykit?

-Josh

I've marked the D-Bus part of this bug Invalid, leaving the PK part open

Same situation on a clean install of Lucid

On my machine, top reports polkitd as consuming 1.5 gigabytes of resources and consistently hogging 30% of the CPU. This appears to happen after leaving the computer on and idle for an extended period of time (e.g. overnight).

Please let me know what diagnostics I can provide to help resolve this issue, and how to obtain them.

In my case, syslog is going crazy with these lines being output multiple times per second:

Mar 26 13:46:20 europa pulseaudio[20254]: module.c: Failed to load module "module-alsa-sink" (argument: "sink_name=M2496_out device=hw:M2496 format=s32le channels=10 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7"): initialization failed.
Mar 26 13:46:20 europa pulseaudio[20254]: main.c: Module load failed.
Mar 26 13:46:20 europa pulseaudio[20254]: main.c: Failed to initialize daemon.
Mar 26 13:46:20 europa pulseaudio[20252]: main.c: Daemon startup failed.
Mar 26 13:46:20 europa rtkit-daemon[1326]: Warning: Reached burst limit for user '1000', denying request.
Mar 26 13:46:20 europa rtkit-daemon[1326]: last message repeated 14 times

Based on this, I now wonder whether this also shows buggy behaviour in PulseAudio.

In any case, I don't believe that PulseAudio should be asked to spawn repeatedly when it's failing to load.

I am experiencing this upon upgrading from Karmic to Lucid Beta 2. The process "polkitd" is sucking up a lot of CPU and accumulates memory usage over time until it maxes out the memory. This is also affecting dbus-daemon. And yes, PulseAudio does seem to take up quite a bit of CPU at times.

My current workaround for this issue is the following cron job:

*/30 * * * * root killall -KILL polkitd

since regularly killing the process doesn't appear to affect the system negatively in any way.

I also had this or a similar problem. "polkitd" used lots of my resources.
My "dbus-monitor --system" output looked the same, but syslog is a little bit different to Alex Peters.
syslog showed this messages:
Apr 10 00:29:38 localhost pulseaudio[4468]: module-device-restore.c: Failed to open volume database '/home/mikey/.pulse/14e15c3974578d407ec6bec04bbe12c0-device-volumes': Permission denied
Apr 10 00:29:38 localhost pulseaudio[4468]: module.c: Failed to load module "module-device-restore" (argument: ""): initialization failed.
Apr 10 00:29:38 localhost pulseaudio[4468]: main.c: Module load failed.
Apr 10 00:29:38 localhost pulseaudio[4468]: main.c: Failed to initialize daemon.
Apr 10 00:29:38 localhost pulseaudio[4466]: main.c: Daemon startup failed.
Apr 10 00:29:38 localhost rtkit-daemon[1518]: Warning: Reached burst limit for user '1000', denying request.

I suspect it was because i copied my home folder from another machine so that the symlink to the file in tmp wasn't set correctly (maybe also after an upgrade). After deleting my "~/.pulse/" directory the problem disappeared.

I don't know if this is the exactly same problem, as the opener of the bug report has, but maybe it helps.

No, removing ~/.pulse/ didn't fix the problem.

Found the problem, but in fixing it I have no idea what fixed it. Someone suggested to me that the problem was one of the hidden folders in the Home directory. I went through a few folders that I thought might have been problems, and in doing so was able to fix it. Unfortunately, I don't remember what I deleted, only that it was one of those that can respawn (so it isn't any of the application data directories). Maybe it was .qt?

Memory leak still persists, though slower than it was.

Oh, and also, got the CPU leak problem again. However, the fix this time is to delete ~/.pulse. Must have been caused by a recent update. Time will tell if this also fixes the memory leak.

I had the same problem because of OSS.
I removed it, now pulse is back and everything is fine.

I found on xubuntu 10.10 (upgraded from 09.10) dbus-daemon using 67% and that making 100%cpu used
then read this and tryd removing .pulse
then in gigolo unmount Windows partition
BUT needed sudo
so i sudo gigolo then unmounted Windows partition and closed Gigolo
then tryd also removing cd rom and after few seconds dbus-daemon was 0%
SO one of theese thing helped.

tryd putting CD back again that didnt made 100%cpu for a long time.
after restart if Windows mounting will be making 100% ill be back and tell u otherwise bye for now

Same here on a rather old Sony notebook.
Deactivating acpid calmed dbus, policykit and kde down.
(Unfortunately I did not jet understand which ACPI function caused the problem - it's not on my own notebook.)

On Precise, I seem to be suffering from this bug too. I have a laptop that I suspend/resume several times a day. After a few days doing this routine, resume become slower and slower. And when I do a "top" after resume, I notice that polykitd is pretty high (40 - 60%), then gnome-shell is at 100% for a few dozen seconds...

If I reboot my laptop, everything is fine again for some time.