[kde-linux] Updating System Configuration
1i5t5.duncan at cox.net
Sun Dec 13 21:39:51 UTC 2009
Kevin Krammer posted on Sun, 13 Dec 2009 14:03:54 +0100 as excerpted:
> On Sunday, 2009-12-13, David Baron wrote:
>> This is a bug from the kde3.5 days or longer:
>> When changing a parameter, i.e. to get dolphin back as my file manager
>> after 4.3.4 upgrade set this back to konqueror ... the progress bar
>> loops, each time at half the speed ad nauseum. If I stop it, I will
>> usually not have any changes made.
> What does "half the speed" mean?
> Compared to what?
> I just tried the same change (on 4.3.2) and I get a progress dialog
> which shows percentage (obviously estimates, it vanished befor reaching
> 100%). Switch from Dolphin to Konqueror took about 6 seconds, switch
> back about 2. First value would probably also be 2 seconds on hot disk
I'm guessing it's a problem with a "stuck" kded (kde daemon, IIRC, the
component that checks for updated config files and updates the binary
config cache accordingly).
I had the same problem here for a few weeks, during I believe it was the
Linux 2.6.31 development cycle. (I've run the kernel rcs for years and
have been doing live git, for bisecting purposes among other reasons, for
a year or so now.) In my case, it was due to them changing the way
dnotify/inotify/fnotify/whatever worked, and breaking it during the
development cycle for a few weeks. A very loose description (not
intended to be technically accurate) is that kded would get the signal
from the kernel that something changed, and try to figure out what it
was, but that's the part that was broken, as the kernel would never
return with the answer to that question, thus keeping kded hung up
waiting for it.
Well, as anyone who has had to deal with a stuck kded knows, at least if
they realized that's what it was, a stuck kded pretty quickly brings most
of the rest of kde to its knees as well, because various apps are
constantly checking with kded to see if their config has changed. And
when they do, /they/ get stuck too, waiting on kded...
What I discovered worked for me (as long as too much wasn't hungup yet),
was manually doing a killall kded (switching to a CLI console, logging in
there, and issuing the killall kded there, so I didn't get something
/else/ in kde stuck, trying to open a konsole window or do it from
krunner... which would of course check its config and get stuck trying to
do so since kded wasn't responding, I think I had to "kill with extreme
prejudice", that is, "killall -9 kded"). Once the stuck kded was out of
the way, kde would replace it with a new instance, and everything could
People who don't know how to login at the CLI and do the killall thing
would have probably had to restart kde, except then they'd probably not
know how to do that either in that case, so it'd be a full reboot. =:^(
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
More information about the kde-linux