[kde-linux] Unpopulated Control-Center window

[Duncan]

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

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[2004]: 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
> kcontrol.

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