[kde-linux] Unpopulated Control-Center window
1i5t5.duncan at cox.net
Tue Dec 1 00:45:04 UTC 2009
Stan Goodman posted on Mon, 30 Nov 2009 21:40:53 +0200 as excerpted:
> At 18:31:11 on Monday Monday 30 November 2009, Werner Joss
> <werner at hoernerfranzracing.de> wrote:
>> Am Monday 30 November 2009 17:21:27 schrieb Stan Goodman:
>> > I'd be grateful for advice on how to restore this functionality.
>> maybe running kbuildsycoca --global helps (kbuildsycoca4 for kde4) -
>> this should rebuild the control center database/cache.
> This is what happened:
> # kbuildsycoca --global
> Warning: kbuildkbuildsycoca is unable to register with DCOP
"kdesycoca" is I believe short for "kde system config cache" (kde, plus
the first two letters of each word thereafter). Unlike, for example,
MSWormOS, KDE doesn't have a binary blob registry, but rather, chose the
*nix way of configuration, text based configuration files -- rather a lot
of them for something as big as kde. But accessing and parsing all these
text files is slow, so the data is saved into the "kdesycoca" (again,
system config cache) binary cache, and under normal conditions,
applications simply use the data as it's found, there.
It then becomes kbuildsycoca's job to update the kdesycoca database when
anything besides kde touches it. (When kde apps change their own config,
the system updates both the text file and the running dcop/dbus.
kbuildsycoca is designed to bring in changes made thru non-kde means,
editing the config files directly with a text editor, for instance, or
when the package manager installs or uninstalls something.) When kde
starts, kbuildsycoca normally runs automatically in incremental mode,
doing a quick check to see what config files if any have changed and
updating that part of the config cache. However, sometimes that doesn't
catch all the changes. If from a terminal (konsole window or CLI login)
you run kbuildsycoca (kbuildsycoca4 for kde4) --help, you'll get a list
of command line options, including the --global and --noincremental
options we're interested in here. --noincremental forces a reread of all
text files, regardless of whether they'd be detected as changed or not.
--global creates the global database from scratch. (FWIW, I'm not sure
what the difference between them might be. Perhaps --noincremental only
checks files known to exist while --global checks all known locations for
new files, as well?)
> That sounds like the reason the problem exists in the first place.
dcop for kde3, now a common dbus, used by both kde4 and gnome, is the
system message bus -- the way dcop/dbus enabled apps talk to each other.
If there's something wrong with things as there is if you don't see a
populated kcontrol, dcop may indeed not be running. It seems
particularly sensitive to kdesycoca corruption, and it's not unusual at
all to have it crash (silently, you only know it happened when stuff
starts acting weird) as a result.
kbuildsycoca (I expect that second "kbuild", as in kbuildkbuildsycoca,
above, is a typo) will in my experience then need to be run twice, the
first time with the mentioned error but fixing things up at least enough
to run dcop, the second time succeeding, ensuring that any loose ends are
fixed up as well.
Now there are some "interesting" (as in that old said to be Chinese
curse, may you live in "interesting" times) problems when kde3 and kde4
are installed on the same box, especially when you try to run apps from
one in the other. Depending on the setup (generally, depending on
whether the distribution has set it up so both can run together or not,
and whether the sysadmin has perhaps changed some settings, possibly long
before kde4 ever entered the picture, such that the distribution's
working cohabitation config breaks), both the kdesycocas might be
fighting each other, trying to use the same cache file, each in turn
overwriting the other, depending on whether a kde3 or kde4 app was run
last. I had this problem for awhile, so I know how frustrating it can
be. But while that's the most obvious problem, other more complex
problems exist as well. Again depending on the setup, the kde3 and kde4
apps may be overwriting each others text configs, thus corrupting the
data used to generate the kdesycoca in the first place. If that's
happening, it's possible kbuildsycoca won't be able to make sense of
things at all, and there'll be no way to get a sensible config. In this
case, checking the sysadmin's (or user's) own settings to see if for
example, the KDEDIR or KDESYCOCA environmental variables are being set
and exported, thus thwarting the distribution's efforts to keep things
separate, might help. If neither the user nor the sysadmin on the local
system has changed such settings, perhaps the distribution isn't setup to
allow both kde3 and kde4 in parallel. In that case, the old
recommendation from the kde4 developer docs might help: run only kde3 OR
kde4 apps as a single user. Use a separate user to run apps from the
FWIW, the problems I had here were a combination of my own settings
fighting the distribution settings, and the distribution not getting it
quite right for some time. Once someone from the distribution's kde
project blogged that they thought they had it worked out, and to check
the individual system and user settings and NOT set specific variables
like the two mentioned above, and I unset the ones I had been setting,
everything in that regard "just worked". In fact, it worked so well that
I was able to switch to kde4 incrementally, an application at a time, by
uninstalling the kde3 app so the kde4 app would be used, while still in
kde3, setting up that kde4 app as I wanted it, then moving on to the next
one. So that's what I did with konqueror, konsole, kmail, etc. Then for
kwin, I killed the kde3 kwin and started the kde4 kwin, configuring it
using kcontrol4 (generically aka system settings, altho it's kde4
settings it controls, NOT general system settings!). Once /that/ was
done, the only critical thing left was plasma itself. I quit kde3 and
started kde4 at that point, and configured plasma-desktop from there.
Obviously, that would not have worked, had the kde3 and kde4 stuff still
been fighting each other, so the distribution did a pretty good job of
getting them working together... once I got the kde3-only era vars I had
set out of the way. =:^) FWIW, I was eventually able to uninstall kde3
and qt3 entirely, tho it took awhile to find replacements for the kde3
functionality (such as global multikey khotkeys) that remains broken in
kde4, in that case, apparently permanently, according to the bug.
Meanwhile, there's another area the problem could be in, as well. I left
this for last as I don't remember the details for kde3, but perhaps it
can at least point you in the right direction, if you get this far
without a fix. In general, the desktop file entries that tell kcontrol3
what menu items (for that's what they are) to include in kcontrol are
like any other kmenu desktop file entries... but for two changes. One,
the kcontrol entries are hidden by default, and thus do NOT display on
the menu as they would otherwise. IIRC this is accomplished with a
HIDDEN=true entry in the file, or some such. That explains why they
aren't normally on the menu, even tho they're mostly ordinary menu
entries. Two, I think they have a kcontrol=true or similar entry (I
think that one's something different, but if you find the associated
desktop files, you should recognized the line) of some kind, as well.
This is what actually tells kcontrol that it should appear in it.
Without that, it wouldn't appear in kcontrol.
Finally, there's one other change in this area, with two parts.
Somewhere, I think it's an environmental var but don't recall exactly,
there's a setting that tells kcontrol which submenu of the kmenu to look
in to find its control modules. There's a default, to .hidden I think
(with the whole submenu hidden, again with a desktop file entry,
HIDDEN=true or some such), if the variable (or whatever) isn't set, but
regardless of whether it's using the default or is pointed elsewhere, if
that submenu doesn't exist or does but isn't what that setting is pointed
at, all the desktop file entries for all the kcontrol applets may be
setup perfectly fine elsewhere in the kmenu, but kmenu will still appear
empty, because it's pointed at the wrong place to look for them.
I actually had this happen to me at one point as well. Thus, I remember
it, but it was some time ago and since I only have kde4 installed now,
it's not like I can verify the details too easily. But maybe there's
enough there to at least point you in the right direction, and by looking
around on your system and googling, you can find the rest.
> I should also mention that upon boot, there is a dialog box, as follows:
> x console <2>
> smartd: Device: /dev/sda [SAT], 2 offline uncorrectable sectors
> Console log
> This seems to mean that I have two bad sectors in the area of the HD
> used by this OS. I suppose this may be what is behind the non-functional
If they're detected and offline, then reinstalling whatever was on them
should fix the problem, since they're now marked as bad. So try that if
you need to. But I suspect the problem has been there for awhile and
isn't the problem in this case. Unless it just started showing that,
and/or you see the uncorrectable sector numbers start increasing! If
they start increasing rather regularly, you better make sure your backups
are up2date and tested to work, or absent that, shut things down and get
a new disk *NOW*, praying that the old one survives long enough to get
the data you need off of it transferred to the new one.
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