kded4 - high cpu usage

[Duncan]

Sergej Pupykin posted on Thu, 07 Apr 2011 01:38:27 +0400 as excerpted:

> after KDE 4.6.2 upgrade process "kdeinit4: kded4 [kdeinit]" eats 100%
> cpu imediately after start. I temporary fixed it by line:
> (sleep 20 ; kill `ps fax|grep 'kdeinit4: kded4 \[kdeinit\]' | awk --
> '{print $1}'` ) &
> in autostart.
> 
> How can I debug it?
> 
> (ArchLinux/x86_64)

Gentoo/~amd64 here, FWIW.  I've not done the 4.6.2 upgrade yet myself but 
expect to by the end of the week.

A hint on that kill `ps | grep` bit: take a look at the pgrep and pkill 
commands/manpages.  As they're part of the same procps package as ps, they 
should already be on your system.  (They're still a rather newly 
discovered toy for me here, too. =:^)

For the 100% CPU thing, the first thing to determine is whether it's user-
config or general system related.  With kde not running, try moving your 
$KDEHOME dir (by default ~/.kde4) and ~/.config dirs elsewhere 
temporarily, then start kde.  If it starts fine, the problem must be in 
the user config.  If it doesn't, barring a very small possibility it's 
elsewhere in the user config (you could try a totally new user to be 
sure), it's a system issue.  FWIW, I've had both issues happen with kde 
upgrades here, at different times.

If it's user config as I'd expect is most likely, you have a couple 
choices.  If you're not a strong customizer, it may be simplest to simply 
blow away that bad config (tho I'd keep the backup for a bit to be sure 
there's no data in it I need) and recustomize whatever needs it.  However, 
that's not an idea a strong customizer such as myself finds palatable at 
all, neither does it satisfy my curiosity as to what it might be choking 
on.

The heavy-customizer config option is what git calls the bisect method.  
It's somewhat brute-force tedious but requires little knowledge of 
internals and is generally quite effective.  The idea is to repetitively 
split the potential problem domain in half and test, narrowing down on 
each cycle, until you find the problem.  You can then eliminate just that 
problem (either the whole file or the line in the file, depending on how 
far you took it), without touching the rest of your config.

Start with kde stopped again.  Blow away the ~/.kde4 and ~/.config dirs 
just created by that first test and copy back just ONE of them (say 
~/.config) from the backup.  Restart kde and again check for the problem.  
You now know which of those two dirs the problem is in based on the 
result.  Quit kde again.  If the problem did NOT occur, you can leave that 
config there (it's fine), blow away the testing stub that got recreated 
for the other half, and copy half of the remainder back (now roughly a 
quarter of the whole, say, all of ~/.kde4 but the apps subdir).  If it DID 
occur, the problem is in the half you tested, so blow both that and the 
testing stub dirs it recreated away, and copy back the OTHER half, plus 
only half of what you tested.  In either case, you'll now have roughly 3/4 
of the original in place, a good half, plus half of the bad half, for the 
next testing cycle.

Repeat the cycle, halving the potential problem area each time, narrowing 
down first to subdir, then to a file within that subdir.  Once you reach 
the file level you can either stop, just blowing away and recustomizing 
what was in that file, or switch from filesystem ops to text-editor ops.  
If you keep going, narrow it down to a config section within the file, 
then, hopefully, an individual line within that section (tho sometimes 
you'll find a whole section is bad, or a corrupted test file that suddenly 
turns binary).  Once you have the individual problem section or line 
within that section, blowing only that bit away and recustomizing it 
should be easy enough.

If it's the system, not the user config, things get a bit trickier.  
Particularly if you built part of the packages yourself, however, the 
problem can sometimes be a reverse dependency -- you upgraded a library, 
but some other library that wasn't upgraded depends on the old version.  
Gentoo has a nice script to help find this sort of thing, called revdep-
rebuild.  Given that arch users often build their own packages as well, 
I'd expect they have something similar.

It's also possible in theory, tho I've never actually seen it happen, that 
the system kde config is screwed up.  Depending on where kde is placed on 
the system, this will be in /usr/share/config or something similar
(/opt/share/config? /usr/local/share/config?).  If it's a problem there, 
it's likely due to a packaging or upgrade issue, tho of course it could be 
a corrupted filesystem or the like as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
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.