Process gconfd-2 causes cpu overuse and overheat

I'm seeing the same behaviour on a current jaunty system: In my case gconfd leads to idling at 100% and stopping it reduces activity to about 12%. Killing gconfd-2 does not help, it is respawned immediately.

According to iotop gconfd-2 is continuously writing to the disk with about 40kB/s, and the file ~/.gconfd/saved_state is growing until it's around 1.2MB and then starting again.

I don't know if it is of any help: Here an strace of ~10s of gconfd-2 running.

the issue is probably not a gconf one but a client application doing lot of read or write in the database

Any idea how I could find out which application is responsible...? According to http://projects.gnome.org/gconf/ gconfd-2 should be logging into the user.log but it isn't (my syslog.conf contains "user.* /var/log/user.log" and pulseaudio is logging into that file). Also sending a USR1 signal does not change anything.

not sure how to watch the activity, did you try with an another user account to see if you still get the bug?

Actually I managed to get rid of the problem now (the problem did not appear with a different user account): I found out that the saved_states file always repeated four entries like
ADD ... "def" "/desktop/gnome/sound" "..."
ADD ... "def" "/desktop/gnome/sound" "..."
ADD ... "def" "/desktop/gnome" "..."
ADD ... "def" "/apps/gnome-settings/vino" "..."

over and over again. So vino seems to be important and indeed, after switching off the remote desktop support the problem went away :-) So it might be related to bug #340515 and I'll check the comments there and upstream.
But please leave the bug open - I kind of took over the bug and the OP might have a different problem.

Thanks for your responses.

For me it was fusion-icon, which I had in the startup applications list. Disabling it fixed the problem. Manually starting it brought it back.

I dunno exactly what caused the problem, a reinstall solved it, however it might be a good idea that the process be patched in some way that would halt itself if stuck looping like this for too long to prevent hardware failure as an unattended system could be damaged by overheating.

I will leave it up to the admins to close the bug as it is no longer affecting me.

Sorry for spamming but I was too quick with blaming fusion-icon. In my case it is a problem between metacity and compiz like described in this bug: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/389686

those issues are not gconf ones but buggy client software

From what I can see, on bootup its starting a metacity process, and calling anything with --replace isnt removing that original metacity process. Killing the plain metacity process fixes it for me every time.

For instance, if I boot with no compiz and change metacity to use compositing via gconf-editor, it starts a new metacity --replace process but leaves the old one there and I get 100% cpu usage with 10% cpu usage in gconfd-2 being the highest visible thing.

robert 3813 2.9 0.7 21488 11092 ? S 19:59 0:03 metacity --replace
robert 4563 0.0 0.4 18868 6640 ? R 20:01 0:00 metacity

Killing the 4563 metacity process cures it. The same thing happens when I use compiz --replace.

Additionally, if I kill the plain metacity process so I only have metacity --replace running, I am able to start compiz via appearance preferences whereas I cannot start it with that metacity process still running.

The compiz/metacity --replace problem is being discussed in bug 389686

I had this issue on Lucid 10.04 upgraded from 9.10 it is probably a duplicate of:
Metacity - https://bugs.launchpad.net/metacity/+bug/150721
GDM - https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/526379
Gconf - https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/293535

simply a side effect of Metacity running twice as "sudo ps aux | grep metacity" shows,
rm ~/.config/autostart/metacity.desktop solved it for me .