policykit cause high dbus-daemon cpu usage

[Joshua Gardner]

Binary package hint: dbus

When resuming from suspend, the system dbus-daemon (the one that runs as user messagebus) starts to run with 30%+ CPU usage. This started a couple of days ago (9/6/09). I can't find any particular reason that it does it besides that it appears to be triggered by resuming from suspend. The only way to get it back is to log out and restart dbus from the console.

[Joshua Gardner (cellofellow)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

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

[Joshua Gardner (cellofellow)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Joshua Gardner (cellofellow)]

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

[Joshua Gardner (cellofellow)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

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

[Katsudon (katsudon)]

Same situation on a clean install of Lucid

[Alex Peters (alex-peters)]

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.

[Alex Peters (alex-peters)]

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.

[Joshua Solomon (jdsbluedevl)]

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.

[Alex Peters (alex-peters)]

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.

[Michael Rodler (michael-r)]

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.

[Joshua Solomon (jdsbluedevl)]

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

[Joshua Solomon (jdsbluedevl)]

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?

[Joshua Solomon (jdsbluedevl)]

Memory leak still persists, though slower than it was.

[Joshua Solomon (jdsbluedevl)]

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.

[Daroczi Krisztián (darkriszty)]

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

[Jānis Kangarooo (kangarooo)]

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

[Steven Schmidt (steven-7t)]

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

[Julien Olivier (julo)]

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.

[Esmaeil Nikfekr (e-nikfekr)]

To troubleshoot high CPU usage caused by the dbus-daemon process, you can use the
"$ dbus-monitor --session"
command to monitor the messages being sent through dbus. If you notice a particular application sending a large number of messages to dbus-daemon, it may be the culprit. In my case, I discovered that my break taker app was sending lots of messages to dbus-daemon. After stopping it, the dbus-daemon CPU usage returned to normal. To identify if there is another app causing this issue, you can use the same command and observe if any message is frequently being sent or not.