CPU always 100% CPU
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gconf (Ubuntu) |
Invalid
|
Low
|
Unassigned | ||
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 : | #1 |
Changed in gconf: | |
assignee: | nobody → desktop-bugs |
importance: | Undecided → Low |
status: | New → Incomplete |
François GUÉRIN (frague) wrote : | #2 |
- htop_screenshot.png Edit (113.0 KiB, image/png)
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 : | #3 |
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 : | #4 |
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@
Detected PCI ID for VGA:
Checking for texture_
Trying again with indirect rendering:
Checking for texture_
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/
/usr/bin/
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 : | #5 |
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_
at /build/
max_priority = 2147483647
timeout = 22440
some_ready = <value optimized out>
nfds = 51
allocated_nfds = <value optimized out>
fds = (GPollFD *) 0xcee440
__PRETTY_
#2 0x00007f7c5a1a2a3d in IA__g_main_loop_run (loop=0x9ccfd0) at /build/
self = (GThread *) 0x9bad90
__PRETTY_
#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 : | #6 |
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/
For your reference, the contents of that ~/.config/
[Desktop Entry]
Type=Application
Encoding=UTF-8
Version=1.0
Name=No Name
Name[en_
Comment[
Comment=Window Manager
Exec=/usr/
X-GNOME-
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 : | #7 |
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 : | #8 |
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://
huiii (a00ps) wrote : | #9 |
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 : | #10 |
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 : | #11 |
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 : | #12 |
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 : | #14 |
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>
2)
open terminal and do:
$ sudo gedit /home/where/
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/
4)
and then under
system>
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 : | #15 |
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/
and this seems to have done the trick.
Mikl (michael-dufosse) wrote : | #16 |
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 : | #17 |
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 : | #18 |
Sebastien Bacher (seb128) wrote : | #19 |
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 : | #20 |
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/
I had to login/logout several times though in order to spot the culprit... Hope this helps...
affects: | ubuntu → gconf (Ubuntu) |
Changed in gconf (Ubuntu): | |
status: | Incomplete → Confirmed |
D J Gardner (djgardner) wrote : | #21 |
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_
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_
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_
CORBA_string_
g_free(0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 0x11d56b1
gconf_locale_
gconf_invalid_
gconf_log(7, 0x40bfd0, 0x11d56b1, 0x40c296, 88) = 0x60f7a0
gconf_locale_
g_str_hash(
g_str_equal(
<... gconf_locale_
time(NULL) = 1243842609
Killing gconfd-2 just makes it respawn and the problem is not resolved.
Sebastien Bacher (seb128) wrote : | #22 |
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 : | #23 |
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 : | #24 |
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 : | #25 |
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 : | #26 |
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 : | #27 |
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-appearanc
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.
Dev El Cuy (develcuy) wrote : | #28 |
I can confirm that #25 helped me to resolve my problem, so doing #26 fixed it :)
J. Alves (alvesjmp) wrote : | #29 |
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 : | #30 |
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 : | #31 |
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 : | #32 |
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.
thanks for the report, is the gconf using 100% or 10% your description doesn't match the summary, can you clarify please? thanks.