[kde-linux] KDE-4.3.2 settings - Regional & Language

[Duncan]

Dr. Edgar Alwers posted on Mon, 14 Dec 2009 15:53:03 +0100 as excerpted:

> we have at home two KDE-4.3.2 installations ( Linux from Scratch ), one
> on a PC, one on an Laptop. As we need to configure the money settings (
> decimal symbol, thousends separator ) for kmymoney, we try to do this
> under settings -
>> Regional & Language.
> 
> It happens, that in the Laptop this makes no problems. For the PC
> however, the attempt to open "Regional & Language" ends allways with a
> crash. Crashhandler says "Executable: systemsettings PID: 4673 Signal: 6
> (Aborted)" and nothing more.
> 
> I would think, that I did the same installation on both machines, but
> perhaps somebody can point me to what I could do or try in order to
> access this coin of the settings menu ? google did not help.

It sounds like the locale config file for the one machine is corrupted.  
You may have to find it, delete it (maybe from the CLI or gnome or 
something outside kde, or logged into kde as root, tho the latter is 
seriously discouraged as there's too much that can go wrong), and /then/ 
try it.

But meanwhile, you can /try/ accessing that specific kcontrol module (aka 
kcm, at least that bit hasn't been stripped of its identity and 
generically mislabeled as system settings when it has little or nothing 
to do with actual system settings and everything to do with kde control) 
and see if that works, tho I expect it too will crash.

To get a list of kcms and their description, run this from a konsole 
window:

kcmshell4 --list

Taking a look at the list (and verifying by running it here), it looks 
like the following command and module is what you want:

kcmshell4 language

As I mentioned above, however, I expect that to crash as well, due to the 
same corrupted config.

So now we need to know what it's loading when it crashes, or, more 
simply, where its config is, since I suspect that's the problem.  Now I 
personally have a pretty good idea from past experience where to look, 
but if I can help you understand the process, the next time you may be 
able to fix it on your own -- as will, very possibly, others reading this 
post either now or coming across it later via google or whatever.

What we need is a tracer program that will hook into our target, and tell 
us what it's doing, at least as far as system level calls go.  More 
precisely, since we suspect it's a corrupt file issue, we're mostly 
interested in what files its trying to access, and which one it chokes on.

As it happens, there is such a tracer program, called strace (short for 
system-call trace, I believe).  You may have to install it if it's not 
installed by default.

Once strace is installed, you can run it with the kcmshell command above 
as parameters, but you'll get WAYYYY too much output to really do 
anything with.  So we have to filter it...  First, we'll tell strace that 
all we want to see is file-open calls, thus eliminating everything else.  
However, a typical kde program will still have hundreds or thousands of 
lines of file-open calls (you definitely get a new appreciation for all 
the work the computer is actually doing behind the scenes for you, using 
strace!), everything from generic kde configuration, to icons and color 
schemes, to all the shared libraries it has to load, none of which 
interest us (unless it's causing the crash, but then other things would 
be crashing too, as they try to access the same data), and many of these 
it looks for in several places before it actually finds the file it 
wants.  So we pipe strace's output to grep, and filter enough of the 
noise out, so hopefully we can find the file we're looking for in what 
remains.

Here's the strace command line before the pipe to grep.  You can of 
course run strace --help or man strace, to get some idea of what else can 
be traced, but what we're doing here is telling it that we're only 
interested in file-open calls (which is, most of the time, how I use it 
myself, not being advanced enough to be able to actually use most of the 
other possible output).  Oh, and since many programs run a launcher, 
which does something before launching what we're really interested in, we 
add the -f, trace forked processes as well.  It doesn't appear to be 
needed in this case, as if there was a fork, with this option strace 
would precede each line of output with the PID (process ID number) of the 
process doing that action, but I'm throwing it in here as it doesn't 
hurt, and someday, if you use strace enough, you'll eventually come 
across a trace where the interesting stuff happens in the fork, not the 
original straced process.

strace -eopen -f kcmshell4 language

Still waaayyy too much output to be of any use, right?

Now let's pipe that to grep and start removing some of the noise.  
First, since strace outputs to STDERR instead of STDOUT, we have to 
redirect strace's STDERR (file descriptor 2) to STDOUT (fd 1), so grep 
sees it.  For grep, we'll start by only listing files in our homedir. 
Replace the path as appropriate for your own user's home dir:

strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user

That should be less output now (try scrolling your konsole output to see 
if you want), as we've filtered out all the accesses to system libraries, 
icons, the general system kde config, etc, but it's still a lot to sift 
thru.

Normally, grep outputs lines containing our search pattern, but we don't 
know it yet here, so we'll use grep's -v option to filter out patterns we 
DON'T want to see.  We probably aren't interested in all the lock files I 
see, at least here, so let's filter those out.  The below is getting too 
long for one line as posted, but it's one command line, even if it takes 
more than one konsole line to display it too:

strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v 
'lock'

Getting MUCH more manageable now, but we can filter out the ENOENT 
accesses as well.  Note the use of | as logical OR in the pattern, and 
that it has to be escaped with \.  There'd be more escapes we'd have to 
do as well, as the shell would interpret those characters, but we're 
protecting it from that with the single-quotes:

strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v 
'lock\|ENOENT'

Let's get rid of the remaining cache, fonts, icons, cursors, and X 
related (.ICE*, .X*, the leading dot must be escaped as it means "any 
character" in regex, and we want a literal dot, not any old character) 
files as well.  Some of these you may not have, some you will, but it 
doesn't hurt to filter out what isn't there anyway.  Of course, this gets 
a bit complicated if your username is "icons" or some such! =:^) Then 
you'd have to use a bit longer pattern to distinguish them:

strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v 
'lock\|ENOENT\|cache\|fonts\|icons\|cursors\|\.ICE\|\.X'

One more step, let's remove /some/ of the duplicates, altho it won't 
remove all of them because the result (file handle) will be different in 
some cases.  We could take care of that too, using a pipe to cut, but 
we're already getting down to manageable levels, so we'll stick with just 
this last pipe, thru sort --unique:

strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v 
'lock\|ENOENT\|cache\|fonts\|icons\|cursors\|\.ICE\|\.X' | sort --unique

Here, that leaves me with 14 lines, tho some of the filenames are still 
dups.  Here's the file list with them removed manually.  If the crash 
occurred before it got to them, you may have less.  OTOH, the crash 
handler may pull others into the list, and your installation may be 
different, pulling in others as well:

Trolltech.conf
kcmshellrc
kdeglobals
oxygenrc
locale/

That last one is a directory, thus the trailing /.

It's probably not the kcmshellrc config file itself, and not the oxygenrc 
scheme file.  It /could/ be the Trolltech.conf file, but probably not.  
Thus, it's probably the kdeglobals file if you don't get to locale, or 
something in the locale dir, if you do get to it and there's something 
besides the directory itself listed.  (I'm mostly en_us, which is the 
normal default if there's no locale, thus the lack of files within it, 
here.  You'll likely have further entries in it too, if you're not en_us.)

Now it's mostly just guessing the order, and checking the files.  Were it 
me, in the above list, I'd guess kdeglobals, but there's a fair chance 
you have files listed there that would have been filtered out in the 
ENOENT step above, for me, since I'm running en_us.

Unfortunately, kdeglobals stores a VAST amount of information.  If you've 
customized as much as I do, you won't want to lose it all, and thus won't 
want to simply blow the entire file away.  However, as a quick test, with 
kde shut down (as your normal user at least, so from a text mode login, 
what I'd use, or from gnome or whatever, or if you MUST risk it, logged 
into kde as root instead of as a normal user), RENAME it to something 
else, log back into kde as your normal user (color schemes and etc will 
have likely reset to default as they're stored in kdeglobals as well), 
and see if the problem persists.  If it's gone, you know for sure it's 
kdeglobals.  If not, you know it's not and can try the next file.

If it's kdeglobals, again with kde shut down as your normal user, you can 
try editing it with a normal text editor.  For text mode, your 
distribution probably has nano, pico, or maybe vi or vim, altho they're 
harder for newbies to use.  I personally like mcedit, part of the mc 
package, but that'd be installed separately, not by default, on most 
distributions.

First make a backup of the file, in case your editing screws something 
else up.

What I'd first look for is an obviously corrupted section, binary in an 
otherwise text file, or the like.  If you see something like that, delete 
that part as it's useless in that state anyway, save the file, and try 
that.

If there's no obviously corrupted section, the next place to look is the 
[Locale] section.  You can try editing it manually, or simply blow the 
entire section away, thus resetting to defaults, and go from there.  
That's a relatively small section and it's relatively easy to reconfigure 
my customizations for only that, so I'd go with just blowing it away.

If you try all your user files and it's not one of them, it's possible 
it's in the system config, not the user config.  This is rather unlikely, 
thus the assumption above that it's the user config, but if you've tried 
the likely and the problem persists...

You can approach that in a couple ways.  Perhaps the simplest is to 
create a brand new all-default user, and try running kde as that user.  
If you still get the crash there, you've verified that it's the system 
config, since there wasn't any user config it could be.

If it /is/ the system config, you can go thru the same process as above, 
but instead of the grep /home/user bit, you'd grep -v /home/user, since 
you know it's NOT the user config now.

Hope that helps. =:^)

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