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.
