[kde-linux] Updating System Configuration

[Duncan]

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

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 
again update...

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