CPU always 100% CPU

Bug #293535 reported by François GUÉRIN on 2008-11-04
76
This bug affects 11 people
Affects Status Importance Assigned to Milestone
gconf (Ubuntu)
Low
Unassigned
Nominated for Lucid by Darxus

Bug Description

Binary package hint: gconf

Since i I installed intrepid ibex, the gconfd-2 daemon uses 10-20% CPU. I did put -5 as nice to X.

I uses std packages in intrepid ibex.

Pedro Villavicencio (pedro) wrote :

thanks for the report, is the gconf using 100% or 10% your description doesn't match the summary, can you clarify please? thanks.

Changed in gconf:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
François GUÉRIN (frague) wrote :

Hello,

My CPU is always around 100%, including gconfd-2 daemon that uses almost 10-20% CPU.

Find enclosed the htop screenshot, showing main processes.

I've put my "nice" back to 0 for X11, with dpkg-reconfigure, with the same result.

Thanks

François GUÉRIN (frague) wrote :

Hello,

I disabled Compiz, and the process gconfd-2 daemon use less processor (it is not in the top precesses anymore). The laptop is an old Toshiba Tecra, with a centrino 1.4 GHz, 500 MiB Ram and an ATI Radeon Mobility 9000.

Thanks

François GUÉRIN (frague) wrote :

Hello,

It'is realy a strange thing...

When my session starts, gconfd-2 is running high, with 20% CPU. Compiz in disabled in System > Preference > Appearence.

When I try to launch compiz with the command-line , I have the folowing message (old version, before today's update):

<code>
$ compiz-manager &
[2] 3347
chrystel@lebowski:~$ Checking for Xgl: not present.
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1024x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0"
/usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
Avertissement du gestionnaire de fenêtres : Attempt to perform window operation 26 on window none when operation 26 on none already in effect

[1]- Done compiz-manager
</code>

Compiz does not launch (it worked with hardy), and gconfd-2 goes low CPU (less than 2%), the gnome desktop works nicely with metacity.

I've tryed with the new updated version, with the same result, but no metacity anymore.

Thanks

Lourens Veen (lourens) wrote :

I can confirm this one. I upgraded from Ubuntu 8.04 to 8.10, and since the upgrade gconf2 is eating CPU. After installing glib debug symbols, I got this stack trace for the rampant process:

(gdb) bt full
#0 0x00007f7c59cb41cf in poll () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f7c5a1a23a8 in g_main_context_iterate (context=0x9c36d0, block=1, dispatch=1, self=<value optimized out>)
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:3091
 max_priority = 2147483647
 timeout = 22440
 some_ready = <value optimized out>
 nfds = 51
 allocated_nfds = <value optimized out>
 fds = (GPollFD *) 0xcee440
 __PRETTY_FUNCTION__ = "g_main_context_iterate"
#2 0x00007f7c5a1a2a3d in IA__g_main_loop_run (loop=0x9ccfd0) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
 self = (GThread *) 0x9bad90
 __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#3 0x000000000040b059 in main ()
No symbol table info available.

This seems to be a part of the normal glib main loop. From an strace, it seems that there's a lot of CORBA communication going on (lots of stuff starting with GIOP being written to sockets), but I'm unsure with what.

I've tried disabling desktop effects, but the problem is there with metacity as well as with compiz (which is otherwise working fine).

I also tried to disable more and more of my desktop by killing processes, on the theory that the problem is with some other application keeping gconfd busy all the time, but that didn't help any either.

Looks like I'll be limping along on one core for a while. If there's anything I can do to help debug please let me know.

Lourens Veen (lourens) wrote :

I realised that, as I hadn't seen this problem when I tested with an 8.10 LiveCD, this was likely to be some old settings getting in the way of some new way of doing things in Intrepid. So I made a new user and logged in as that user. Behold, problem gone.

After that it was a matter of bisecting config files. I finally ended up deleting my ~/.config/autostart/metacity.desktop file. As I said above, I use compiz, so I have no need of metacity. I'm not sure why it would be started explicitly from my .config/autostart. Maybe I did something funny with the session editor at some point? And it doesn't explain why gconf would start eating CPU. However, it fixed the problem for me, and right now that's good enough.

For your reference, the contents of that ~/.config/autostart/metacity.desktop were:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Version=1.0
Name=No Name
Name[en_US]=Metacity
Comment[en_US]=Window Manager
Comment=Window Manager
Exec=/usr/bin/metacity
X-GNOME-Autostart-enabled=true

François, could you make a new user and log in as that new user? Does that solve it for you as well?

Magnus Wissler (gmw) wrote :

Can confirm this using a /home with a user that was created using 8.04. I then reinstalled the system as 8.10 (keeping the old /home partition from 8.04). Creating a new user in 8.10 caused no gconfd-2 problems, but logging in as the old user instantly got me a gconfd-2 process eating away at the CPU (30-34% on a quad-core CPU). Renaming the ~/.gconf and ~/.gconf directories to something else fixed the problem, but of course also removed all desktop configuration as well.

Jarek Zgoda (jzgoda) wrote :

I can confirm, removing stale configuration makes gconfd to behave "normally".

I had exactly the same problem after fresh installing 8.10 with /home partition from 8.04 retained. gconfd was constantly eating ~30% of CPU, effectively draining the battery of my laptop in 40 minutes. I asked on ubuntuforums if anybody discovered such weirdness, but got no response (http://ubuntuforums.org/showthread.php?t=983335).

huiii (a00ps) wrote :

I can confirm, removing ~/.gconf did the trick.
i had 20%-30% constant cpu on gconf-2 like all my collegs above, after fresh install ubuntu ibex with seperate /home partition, which caries all the configurations since feisty...
thx sor solution!

huiii (a00ps) wrote :

deleting ~/.gconf is not a solution after all:
it came back,
today, one week later, gconf-2 pushes cpu to 20%.
this is bad.
i cannot always delete ~/.gconf, because i will have to reconfigure everything again,
i consider this as a bad bug.

please help,
thx

huiii (a00ps) wrote :

and i forgot to tell u this:
when this bug appears, the ugly ubuntu-login-sound comes up at login, while it is disabled in the sound-manager...

huiii (a00ps) wrote :

what i discovered in the meantime:
it is not deleting ANY files that solves the problem, but simply restarting xserver with ctrl+alt+backspace does the trick. bizarrr

huiii (a00ps) wrote :

the following did the trick:

i wrote a delay-script for starting up compiz. delayed for 10sec.
since than gconf2 is quiet, behaving nomal.

1)
system>preferences>appearance>visual effects> set to "none"

2)
open terminal and do:

$ sudo gedit /home/where/ever/compizdelay.sh

paste this text and save:

#!/bin/bash
  sleep 10
  compiz --loose-binding --replace &
  emerald --replace &
exit 0

3)
now we need to make it executable:
$ sudo chmod +x /home/where/ever/compizdelay.sh

4)
and then under
system>preferences>sessions> press "add" and browse to where that new script is.

test and reboot and voila, works,,,
if not try to play with the "sleep ..." setting in the script, perhaps on your maschine it needs to sleep longer

Craigus (c-o-hopkins) wrote :

I had the same problem. i had installed Intrepid after reformatting my / partition but still had /home left over from Fedora. I ended up with high CPU usage. I reformatted again to Hardy and the problem was gone. I've just followed the Upgrade process to go Intrepid and the problem has come back.

I tried removing compiz (as I never use it) and that did nothing, and spotted the entry above to remove

~/.config/autostart/metacity.desktop

and this seems to have done the trick.

Mikl (michael-dufosse) wrote :

i had the same problem
In the session manager i unchecked "metacity" wich was redundant with "window manager" and gconfd-2 came back to the normal.

Daniel T Chen (crimsun) wrote :

Reproduced in a distribution upgrade on amd64 from 8.10 to 9.04, and removing ~/.gconf for the affected user(s) and logging back in does work around the symptom.

aotianlong (aotianlong) wrote :

i confirm this

i have double screen

Sebastien Bacher (seb128) wrote :

the isue is not a gconf one but apparently an user setting which triggers lot of gconf use in some software, try to figure which one and reassign the bug there

affects: gconf (Ubuntu) → ubuntu
Changed in ubuntu:
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Shrikaant (shrikaant) wrote :

Backup the ~/.gconf folder or simply rename it to .gconf_old and relogin. A new .gconf will be created with some default settings.

Then move the one of folders from gconf_old to the new gconf and relogin to see until you get that high-cpu usage again. Thus you will have singled out the problem.

For me, the problematic setting was ~/.gconf/desktop/gnome/remote_access. I didnt include this folder in my new settings and now everything is fine.

I had to login/logout several times though in order to spot the culprit... Hope this helps...

D J Gardner (djgardner) on 2009-06-01
affects: ubuntu → gconf (Ubuntu)
Changed in gconf (Ubuntu):
status: Incomplete → Confirmed
D J Gardner (djgardner) wrote :

I've assigned this as a gconf bug, because:
 (a) it fairly clearly is, from the work-arounds
 (b) it just shouldn't happen that certain configuration item should put the program into a loop.
 (c) this bug needs some activity to stop it being deleted.

Features of this bug as I've seen it:

 On upgrading our laptop from intrepid to jaunty (amd64) my login is fine, but my wife's login suffers from gconfd taking 20-20% CPU. Running ltrace on the process gives what seems to be a semi-repeating pattern of:

1. about 400 lines of CORBA_string_dup, gconf_entry_get_is_default, gconf_entry_get_is_writable, gconf_entry_free, CORBA_string_dup, gconf_entry_get_value, gconf_fill_corba_value_from_gconf_value, ....
2. about 400 lines of g_str_hash, which includes an unchanging 6-line repeat (return codes and parameters unchanging)
3. then about 5 pairs of ORBit_small_allocORBit_small_allocbuff,
Then the CORBA_string_dup lines restart

after a while of this I sometimes get this sort of pattern too:
time(NULL) = 1243842609
gconf_sources_query_value(0x113a300, 0x11ed131, 0x11ea560, 1, 0x7ffff5d59d14) = 0
CORBA_string_dup(0x40c726, 0, 0x7ffff5d59d80, 0xffffffff, 0xfefefefefefefeff) = 0x11d56b1
g_free(0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 0x11d56b1
gconf_locale_list_unref(0x11e34c0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 1
gconf_invalid_corba_value(0x11e34c0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 0x11f9ef0
gconf_log(7, 0x40bfd0, 0x11d56b1, 0x40c296, 88) = 0x60f7a0
gconf_locale_cache_get_list(0x148cc20, 0x11d56b1, 0, 1, 0x7ffff5d59da0 <unfinished ...>
g_str_hash(0x11d56b1, 0x11d56b1, 0, 1, 0x7ffff5d59da0) = 0x81510175
g_str_equal(0x11f9e30, 0x11d56b1, 0x4054c0, 0x11d56bc, 0x7ffff5d59da0) = 1
<... gconf_locale_cache_get_list resumed> ) = 0x11e34c0
time(NULL) = 1243842609

Killing gconfd-2 just makes it respawn and the problem is not resolved.

Sebastien Bacher (seb128) wrote :

thank you for you bug report but that's not a gconf issue there is just a client application doing lot of gconf calls

Changed in gconf (Ubuntu):
status: Confirmed → Invalid
D J Gardner (djgardner) wrote :

Hmm further testing shows:

1. Removing .gconf solves the problem for one login, but it returns on second login.
2. I saw occasional defunct copies of metacity in top.
3. Disabling desktop effects seems to solve the problem

So does that make it a metacity / compiz bug?
If I understand you right, there is some probably some client (metacity / compiz?) asking for gconf data, crashing because of it, and re-spawning?

On the other hand I think there could still be a gconf - related solution to the problem, in that gconf potentially has the ability to stop this cycle. It could well see an activity that is suspect (excessive access to a config item) and make it hang for a while, much like init will
stop a task that is respawing too fast...

by the way, all those calls to gconf_log... where does the logging data go?

olksy (noface) wrote :

Dudes, I've found the root of this problems for my PC. Probably, this should help you.

For me that vino remote desktop server was loading gconfd. Trick that fixes problem is to kill vino-server after GNOME login.

pkill -9 vino-server

Then, it resurrects back but stops flooding gconfd.

olksy (noface) wrote :

But, in addition to posted above, that was not all I found out. CPU load goes down even more from 50% to 0%, if I restart metacity:

pkill metacity
nohup metacity >/dev/null &

Anyone can suggest where I should post this GNOME issue ?

aotianlong (aotianlong) wrote :

i was resolved this.

system -> preference -> startup applications -> deselect metacity.

then my cpu usage down to 1 %

hope this will help you.

Seanzer (lee-2817) wrote :

I'm running Karmic Koala, and recent updates have broken compiz.

1. Compiz stopped starting automatically at start-up. I couldn't enable it in gnome-appearance-properties. It seems that compiz loads but then the properties dialog delays for a while and then comes back and says that it could not start compiz. After the dialog appears, the desktop goes back to just plain metacity.

2. I can force compiz to start by using "Startup Applications" but then I have to kill metacity everytime I start-up because it makes gconf-2 go to constant 30% CPU usage.

I doubt that the issue is a Karmic problem as much as just a broken configuration.. I'll add to this when I figure it out.

develCuy (fernando-develcuy) wrote :

I can confirm that #25 helped me to resolve my problem, so doing #26 fixed it :)

J. Alves (alvesjmp) wrote :

Thanks, olksy (#24)!

The "pkill -9 vino-server" solved the problem for me and now my CPU usage is back to the previously normal < 5% when idle.

I do not have metacity listed in my startup apps, but it shows in gPS when not using desktop effects; when using desktop effects, it disappears. Either way, the CPU usage even as I type it now is below 5-10% (single core processor, by the way), lower if not touching anything for a few seconds.

Darxus (darxus) wrote :

I am also seeing this on Karmic.

I also think gconf should not allow another buggy program to use up the CPU. It really needs to throw a user-visible error stating what the problem is, and throttle the other buggy program.

Ah, I believe metacity didn't come up as expected this boot, and I started it from the commandline, so I have two instances. Fighting over gconf?

Yup, killing the older instance made the gconf cpu usage go away, and I could see my window manager get reloaded. This is definitely not the way Ubuntu should handle this.

Elmer Fudd (efuudd) wrote :

Also had Metacity problem. I had enabled Metacity in Startup to fix an earlier problem. An update must have fixed the original problem but left an unnecessary instance of Metacity. As #26, Disable Metacity in Startup Applications and reboot.

Lucid 2.6.32-23 generic-pae
Gnome 2.30.2

Michael Haggerty (mhagger) wrote :

I had similar symptoms under lucid while trying to change my window manager to sawfish--one CPU pegged at 100%, with top showing gconfd-2 using up about 20% and Xorg about 15%. It turns out that the problem was caused by metacity trying to start, realizing that another window manager was running, outputting and error, then being RESTARTED very quickly. "top" didn't list metacity as the culprit because each metacity process was dying so quickly that it didn't show up in the statistics. It was gnome-session that was restarting metacity endlessly, so I suggest that this is a bug in gnome-session (it should somehow give up after a while, and probably show an error dialog).

I described the solution for my problem (which doesn't necessarily apply to this bug) in bug #453115.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers