[kde-linux] Updating System Configuration

[Kevin Krammer]

On Sunday, 2009-12-13, Duncan wrote:
> 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).

The updating is handled by kbuildsycoca4 but kded might watch the directories.
Though user local modifications are more likely to be handled through explicit 
updating.
(I am not even sure that the config cache even includes local modifications)

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

Ah, that sounds bad. Bug on the system level API.
Luckily not happening to a process holding user created data.

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

Actually most applications don't use kded for any config related things, they 
just read/write their config whenever they see fit.
kded is mostly used for cookies, global shortcuts, etc. (used to include 
wallet, but that plugin got moved to its own service for technical reasons).

> 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. =:^(

Since it was stuck on a system call you were lucky to get it killed at all.
Sometimes this more or less requires a reboot (depending on what resource it 
is stuck on)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20091213/870f5b9f/attachment.sig>