plasma-desktop using 100% of 1 core

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 config.new
2. write config.new
3. write config.new
4. close config.new
5. rename config.new 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...
> 
> > Brry <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
> > "http://www.w3.org/TR/REC-html40/strict.dtd">
> > <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.

Barry

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.