Created attachment 765807 [details] KDE screenshot Description of problem: When I login to the MATE desktop on my laptop both CPU's go to 65% CPU usage and remain that way until I log out. Depending on what I do they can go as high as 99% cpu usage. The problem is not limited to my laptop, both my F18 system exhibit the same problem with MATE desktop. I tried running KDE on the same hardware with F18. With KDE the processors are at less that 5% after logging in. I tried with Gnome and there the processors are also over 65% Version-Release number of selected component (if applicable): mate-desktop.x86_64 1.6.1-7.fc18 How reproducible: Always. Steps to Reproduce: 1. Install F18 2. Update to latest 3. Login Actual results: CPU's at 65% or higher Expected results: Should be less that 10% Additional info: Two attachments. One is a desktop snapshot with MATE the other with KDE right after login.
Created attachment 765808 [details] MATE screenshot
see https://bugzilla.redhat.com/show_bug.cgi?id=969663 Seems to be a prob with some settings in your user folder. Can you create a new user account to validate if this issue also ocours?
Created attachment 766928 [details] Home directory that reproduces problem This home directory causes 70+% CPU usage on both processors
A new user does not show the problem. However, I managed to reproduce the problem with the attached user home directory. I configured the following things: 1) Mouse focus follows pointer 2) Remember applications on logout 3) Configure gkrellm with minimal display The system is running >70% CPU on both processors.
(In reply to pgaltieri from comment #4) > A new user does not show the problem. Is it a real problem to delete ~.config/dconf/user and .cache/dconf/user to get a clean MATE configuration? You will lost all done dconf/gsettings settings in MATE which depends on gsettings keys. Sorry for this, but MATE starts with a development version in f18 and a lot changes with gesettings keys aren't in your user dconf configuration. This is a well know dconf limitation that changes with gsettings in a package during a development phase of a package doesn't applied in user dconf settings. My suggestion: Save both files and restart the session without them. I'm pretty shure that this eliminate the high cpu load. If not copy them back and we will further look into the issue. Thank you
(In reply to pgaltieri from comment #4) > 2) Remember applications on logout can you disable this setting?
It looks like this setting is the problem. If I disable it and logout and login again the CPU usage drops to around 4%. If I re-enable the option and logout and login again the CPU usage goes back up to >70%.
Ok, same like in the other bug The session state is stored here. ~.config/mate-session/saved-session/* Clearing this folder should solve your issue, hopefully.
As I said if I don't store session state I don't see the problem. When I save session state the problem comes back.
Weird, that cleaning the folder ~.config/mate-session/saved-session/ doesn't help. Next test: Can you disable caja-autostart in autostart for testing? Normaly the session should now start without 'caja handles the desktop', means no desktop icons and right click menu.
The contents of ~/.config/mate-session/saved-session/ don't matter. What matters is whether I restore my session on login. I can remove all the files in that directory, configure the system to save my session, and logout, but when I login afterwards I'm back to running at 70% or higher. It's the actual restoring of the previous session that triggers the problem, and only for the mate desktop. With the caja desktop disabled and restore previous session enabled, when I login I do not see the high cpu usage.
Ok, the prob is that something is that something in your dconf configuration trigered the start of caja from mate-session. This is wrong because /etc/xdg/autostart7caja-autstart.desktop starts 'caja handles the desktop'. So i suggest to follow my hints from comment 5, this will bring you a clean configuration, half an hour work to configure MATE again and an life without this issue. :) Sorry, i can't do more for you. *** This bug has been marked as a duplicate of bug 969663 ***
(In reply to pgaltieri from comment #11) > The contents of ~/.config/mate-session/saved-session/ don't matter. What > matters is whether I restore my session on login. I can remove all the > files in that directory, configure the system to save my session, and > logout, but when I login afterwards I'm back to running at 70% or higher. > It's the actual restoring of the previous session that triggers the problem, > and only for the mate desktop. > > With the caja desktop disabled and restore previous session enabled, when I > login I do not see the high cpu usage. Sorry, it was late yesterday, forget my last comment. Doing my hints in comment 5 is useless in this case. If you use 'saving the session' than the results are writen in ~/.config/mate-session/saved-session/ during logout , whether this folder is empty or not. Unfortunately mate-session stores also caja in 'restore session' information, in result caja starts double in next session. But now we have two caja processes: one with constant PID and one whose PID is changing every two or so seconds, which means it's dying and the parent is forking new child each time. This caused the high CPU loading. For the moment you can disable caja in autostart if you use 'restore session' as workaround. I will work on better solution. Ok, let us further talk in the the other same report. bug 969663
re-open to fix the issue
mate-file-manager-1.6.1-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-file-manager-1.6.1-9.fc18
Is there a way for me to download and try mate-file-manager-1.6.1-9.fc18? Paolo
When it gets pushed to the updates-testing repo you can run "yum update --enablrepo=updates-testing" or download the RPM directly from koji. You will want m-f-m and m-f-m-extensions rpms if you can't wait for them to be pushed to the updates-testing repo.
Package mate-file-manager-1.6.1-9.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mate-file-manager-1.6.1-9.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12090/mate-file-manager-1.6.1-9.fc18 then log in and leave karma (feedback).
Downloaded and tried out new version of mate-file-manager from test repo and it works. CPU usage is in the 1% to 5% range. Very good :-)
mate-file-manager-1.6.1-9.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.