compiz --replace fails to kill metacity, resulting in cpu overload

[Yotam Benshalom]

Binary package hint: compiz

I use 32-bit Karmic on lg-s1 laptop with mobility radeon x1600.
As of latest compiz update (1:0.8.2-0ubuntu13), my two cpu's are both on constant ~50% load when compiz operates. This happens with the radeon and radeonhd drivers defined in xorg.conf (and checked in xorg's logs).
This does not change when I disable all compiz plugins, both on gconf and flat file backends.
Using 'top' or gnome system monitor does not show any irregular activity from compiz or its wrappers, but killing it frees up the cpu.

I attach my xorg.conf, and will add more data as requested.

[Anton Kraus (done)]

This doesn't seem to be limited to ATI/AMD hardware. The same bug also happens with my Geforce 6600 LE.

[Yotam Benshalom (benshalom)]

Problem found. Compiz was run without the --replace parameter. This resulted in metacity running in the background. I run compiz manually from gnome startup list instead of the appearance window because of another problem, irrelevant to this bug.

Anton, try to run killall metacity. If that frees up your cpu, than all is well - and make sure compiz is run with --replace.

I think the bug can be marked invalid now.

[Anton Kraus (done)]

Thanks. Killing metacity helped return CPU load to normal.

However, there seems to be more to this bug.
You see, I always start compiz with the --replace parameter. Until a few days/weeks ago (I seldom restart) this worked fine. But since sometime in the Karmic development cycle, metacity unexpectedly keeps running in the background, eating lots of CPU cycles.

I can reliably start a Gnome session with metacity, run compiz --replace and have it result in high CPU load until I then do a killall metacity.

[Yotam Benshalom (benshalom)]

I can confirm that. the --replace option is just not working with compiz anymore.
I hope that this is a mere issue with the compiz wrapping script, and not with compiz.real itself.

[Travis Watkins (amaranth)]

Are you using metacity compositing?

[Yotam Benshalom (benshalom)]

Compositing in metacity is not enabled.

P.S. Excessive cpu usage happens whenever metacity runs, regardless whether compiz also runs or not. Also, running metacity --replace crashes my X session.

P.S.S. I checked the compiz wrapper script, which creates the command line to call compiz.real. Apparently, when called with no arguments and metacity running it produces a command which already contains the --replace argument. When I run compiz --replace, it simply add the additional argument to the end of the command line - repeating the argument --replace twice. The argument doesn't do its job either way.

[Travis Watkins (amaranth)]

This seems to be a problem with metacity.

[Hernando Torque (htorque)]

I can confirm this using a Nvidia 6600 GT with Nvidia 185.18.14 drivers.

*) Starting compiz via fusion-icon in the startup applications causes 100% CPU load. Killing either compiz.real or metacity reduces CPU load back to normal.

*) Starting compiz manually after session start with 'compiz --replace' causes 100% CPU load. Killing either compiz.real or metacity reduces CPU load back to normal.

*) After restarting metacity with 'metacity --replace' I can start compiz with 'compiz --replace' without high CPU load.

In my case the high CPU load is caused by gconfd-2, which continuously writes to ~/.gconfd/saved_state

Maybe a duplicate or connected: https://bugs.launchpad.net/ubuntu/+source/gconf2/+bug/390733

[Hernando Torque (htorque)]

Ok, this gconfd-2 thing seems to be the result of 'compiz --replace' starting a loop that triggers this bug: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/150721

Addition to above points:

*) Starting compiz via setting 'Visual Effects' to 'Normal' in 'Appearance Preferences' (and removing all other compiz/fusion-icon autostart entries) works fine. That's why I couldn't reproduce the problem with a new user - 'Normal' is default and compiz was already running.

[Matt Zimmerman (mdz)]

I see a similar effect here. I had been running with desktop effects disabled (metacity), and then re-enabled them (switching to compiz). it seems that gnome-session is continually respawning metacity continuously, chewing up lots of CPU. metacity fails quickly because compiz is already running, but it gets started again immediately.

I think the problem is likely in gnome-session rather than metacity itself, though I haven't investigated.

[Matt Zimmerman (mdz)]

I can also confirm that "killall metacity" breaks the cycle, though I'm not sure why.

~/.xsession-errors is 54MB of:

Window manager warning: Screen 0 on display ":0.0" already has a window manager; try using the --replace option to replace the current window manager.
Window manager warning: Failed to read saved session file /home/mdz/.config/metacity/sessions/1037d2bf8e46f506124701073754142900000192700026.ms: Failed to open file '/home/mdz/.config/metacity/sessions/1037d2bf8e46f506124701073754142900000192700026.ms': No such file or directory

[Matt Zimmerman (mdz)]

Also, at least in my case, compiz *was* correctly run with the --replace parameter:

mdz 22880 0.0 0.0 4020 644 ? S 10:36 0:00 /bin/sh /usr/bin/compiz --replace
mdz 22936 2.5 2.8 400868 86388 ? S 10:36 3:41 /usr/bin/compiz.real --ignore-desktop-hints --replace --replace core ccp

[Chris Coulson (chrisccoulson)]

Re-assigning back to Metacity. It seems Metacity sets SmRestartImmediately when it first runs, and normally sets SmRestartIfRunning on a clean exit, which is perfectly okay. However, the code path which is triggered on startup when Metacity can't control the display (if another WM is running), does not set SmrestartIfRunning before exiting, which can trigger this endless loop of restarting. Fixing that should stop the endless looping.

However, this was also the case in Jaunty, so there must be another underlying issue with the newer version which needs some more investigating. Either there is a code path which is triggered when you run "compiz --replace" which causes Metacity to exit before setting SmRestartIfRunning, or something calls meta_restart (), which spawns a new Metacity independently of the session manager, which then exits immediately after setting SmRestartImmediately, triggering the endless loop mentioned above.

I'll look at this more when I get home.

[Chris Coulson (chrisccoulson)]

I've done some more debugging now. The case where metacity runs but immediately exits without setting SmRestartIfRunning (which also existed in Jaunty) is not an issue, because metacity doesn't set a restart command - so gnome-session won't restart it unless it was autostarted when the session began.

So the only case which triggers this then is when Metacity is autostarted when the session begins, then exits when you run Compiz. In Jaunty, metacity correctly sets SmRestartIfRunning before exiting (I verified this by looking at some debug output from gnome-session), but in Karmic this doesn't happen. In this scenario, gnome-session will respawn it continuously, which is what is happening.

I can see the change which breaks it, but I'm a bit uncomfortable with reverting it without understanding why it is there. Basically, it seems that meta_session_shutdown is called after meta_display_close was already called.

--- metacity-2.25.144/src/core/session.c 2009-02-01 20:33:15.000000000 +0000
+++ metacity-2.27.0/src/core/session.c 2009-02-20 15:26:32.000000000 +0000
@@ -376,6 +376,14 @@ meta_session_shutdown (void)
   SmProp *props[1];
   char hint = SmRestartIfRunning;

+ if (!meta_get_display ())
+ {
+ meta_verbose ("Cannot close session because there is no display");
+ return;
+ }
+
+ warn_about_lame_clients_and_finish_interact (FALSE);
+
   if (session_connection == NULL)
     return;

[Chris Coulson (chrisccoulson)]

I've pushed a change to my branch which fixes this. I'll send this upstream after dinner

[Chris Coulson (chrisccoulson)]

Sent upstream to http://bugzilla.gnome.org/show_bug.cgi?id=588119

[Chris Coulson (chrisccoulson)]

Hmmm, I thought I'd already subscribed u-m-s to this.

[Khairul Aizat Kamarudzzaman (fenris)]

im also having problem with CPU usage .. waiting it to get fix ..

[Nicholas Christian Langkjær Ipsen (ncli)]

Confirmed with a GTX 295 and the latest drivers.

[Roger (r-wiberg)]

I'm not sure what did it, but as of some updates today or late last night I'm also affected. Something's changed to trigger this behaviour, because it's the first I've seen of it in this development cycle.

[Roger (r-wiberg)]

Maybe I should add that I'm seeing this on an Nvidia Quadro NVS 320M running with the Nvidia 190.18 beta drivers.

[GiuseppeVerde (launchpad-digitasaru)]

Did the fix get unfixed? I'm seeing this today on my workstation (didn't see it before, 'cause I upgraded to karmic there after the fix was released)

[Martin Pitt (pitti)]

Chris, upstream discussed and committed a different patch. Could you please test and commit this instead? Thanks!

[Chris Coulson (chrisccoulson)]

Yeah, the proposed upstream patch makes more sense and also moves the warning about windows not supporting session saving to a more sensible code path, so that it doesn't appear on every log out for those applications affected by it. I will test the patch later on.

[Chris Coulson (chrisccoulson)]

I've tested it and pushed the changes to lp:~chrisccoulson/metacity/bug389686

[Launchpad Janitor (janitor)]

This bug was fixed in the package metacity - 1:2.27.0-0ubuntu4

---------------
metacity (1:2.27.0-0ubuntu4) karmic; urgency=low

  * debian/patches/015_set_restartifrunning_on_replace.patch:
    - Make sure that RestartStyleHint is set to RestartIfRunning
      when replaced (LP: #389686).
    - Only display warning dialog for clients that don't implement session
      saving during a "Local" or "Both" SaveYourself request when the user
      wants to save their session state, rather than at the end of every
      session (LP: #35316).
    - Patch taken from GNOME Bug #588119.

 -- Chris Coulson <email address hidden> Wed, 09 Sep 2009 08:59:29 +0200

[Chris Roddy (cmr)]

i am confused, this is 73 days since the fix was released. am i seeing a regression or was the fix not actually pushed to the repositories?

[Emmanuel C (manuco)]

I confirm that I still have this problem despite the fact the bug is marked "fix released".

[coffeemonk (coffeemonk)]

I've also just discovered this bug, recently after turning on metacity's compositing feature (since compiz + intel 945 + dual monitor = crash).

[chris_blues (chris.blues)]

I have the same bug here on a lucid beta2 install, normal desktop installation. I use the NVidia current driver. Compiz activated... Is there some new bugreport for lucid, where to add my cry for help?

xorg and gconfd-2 running overtime eating power, CPU's @ 60% permanently...

[Tebibyte (xiboce08)]

Login into Ubuntu netbook remix 10.04 with "compiz --replace" , "emerald --replace" and "avant-window-navigator" as autostart programs causes
1) CPU overload ... most possible from gcond2
2) hard drive constantly buzy/ in use .... even when machine is innactive
3) performance issues (slow)

killall metacity does not work for me,

Thinking it is metacity related I installed _xfce4_

Booting into an xfce4 session with compiz --replace" , "emerald --replace" and "avant-window-navigator" as autostart programs solved the problem, specifically
1)gconfd2 does not appear when i run "top"
2) hard drive is not constantly in use

[H.-Dirk Schmitt (dirk-computer42)]

Similar problem in maverick for a Fujitsu T4310 notebook.
Running icewm doesn't cause a problem.
Running compiz, metacity or mutter trigger this problem.

Workaround in xorg.conf fixes this problem for me and allow start of gdm again

Section "Extensions"
 Option "Composite" "Disable"
EndSection

[Jan (mrstrauss94)]

I am running compiz in ubuntu 10.10 and it fails to kill metacity here, too. Every time I boot my system, I have to kill metacity (as root) and to start compiz. That really sucks. I hope this bug will be fixed soon.

[Jan (mrstrauss94)]

If I remove compiz from autostart and start it manually from the terminal with "copmiz &" all works fine.