plasma-desktop using 100% of 1 core

Barry Scott barry.scott at
Thu May 17 17:48:36 BST 2012

On Thursday 17 May 2012 04:43:30 Duncan wrote:
> Barry Scott posted on Wed, 16 May 2012 17:37:02 +0100 as excerpted:
> > On Wednesday 16 May 2012 18:14:40 Alex Schuster wrote:
> >> Barry Scott writes:
> >> 
> >> > After a forced reboot of my Fedora 16 system I am seeing
> >> > plasma-desktop use 100% of 1 core after a while. Killing
> >> > plasma-desktop and starting it up again is a temporary work around.
> >> 
> >> Does plasma still react, or is it frozen?
> > 
> > It reacts very slowly.
> FWIW...
> For technical reasons related to qt4, the choice (which I don't really 
> agree with but I'm not the one doing the coding so it's not my say, it 
> was certainly the easiest choice to make, but not the most robust) was 
> made to run all of plasma, including all plasmoids/widgets, as a single-
> threaded app.  That means that if one freezes or goes into an endless 
> loop, plasma itself quits responding.
> This wasn't exactly the best choice possible in terms of robustness, for 
> an app designed to be extensible with plugins (plasmoids in this case) 
> written by all sorts of people of various levels of expertise, as can be 
> found on for example kde-look, which is fully integrated into kde via the 
> get-hot-new-stuff APIs.
> Whatever.  The result is that if plasma continues responding, you know at 
> least that it's not a fully locked-up plasmoid.  But one may still be 
> taking all the CPU available to it, which seems to be your situation.
> If you've loaded any plasmoids from kde-look and you decide to see which 
> plasmoid it might be, those are the the ones I'd try removing first, 
> since presumably, those that ship with kde, and any others packaged by 
> your distro, should be rather more highly quality-checked.

I'm using distro plamoids only. I expect this is a case of a corrupt file.
I'll try and track it down. I agree with the assessment on robustness.

> But in the case of an unclean shutdown, it could be any of them that 
> write to disk, which since the configuration is written to disk, would be 
> most of them.  Chances are, one of those bits written to disk got 
> corrupted in the unclean shutdown.  If you can find and delete, restore 
> from backup, or manually cleanup via editing, the corrupt file, you 
> should be back to normal operation without having to reset your whole 
> customized setup.
> Also check the plasma-desktop-appletsrc file, as wonko/alex mentions.  
> Unfortunately, this file contains most of the config for nearly all 
> plasmoids, containers and activities, including their layout, and while 
> nominally in standard plaintext *.ini file format the file's section 
> dependencies are complex to say the least, so if this file gets corrupted 
> and you don't have a backup, you often end up simply deleting it and 
> having to reconfigure all activities and panels from default.

In our product we have taken to using a pattern of

1. open
2. write
3. write
4. close
5. rename config

Which for single files avoids the corruption of a part written file.

> The moral of the story is, keep a backup of that file!
> Meanwhile...
> > "">
> > <html><head><meta name="qrichtext" content="1" /><style type="text/css">
> Please avoid posting in HTML to the lists.  Keep it plain text and 
> everyone stays happy. =:^)

Oh. I had kmail configured to use plain text for this identity...
Hummm... I cannot find the force plain text option in kmail now.
I'm running 4.8.2.

I'll have to remmember to check it manually.


This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list