[kde-linux] KDE suddenly refuses to start
1i5t5.duncan at cox.net
Tue Jul 7 11:15:13 UTC 2009
"Ronald Fischer" <ynnor at mm.st> posted
1236607429.6989.1304406981 at webmail.messagingengine.com, excerpted below,
on Mon, 09 Mar 2009 15:03:49 +0100:
> Next I did a su root and started KDE, and this worked well, so it can't
> be that the KDE installation itself got broken.
> Any idea where I could look further for analyzing the problem?
[Yeah, I know this is still ~4 months old, but WTH.]
Did you try removing (well, moving elsewhere for backup, if it's heavily
customized) your user's ~/.kde (or whatever it was back in kde2 land, I
was there, briefly after I switched to Linux, but can't remember for
sure, also note there may be a .kdeglobals file or the like, too), to see
if it started correctly with fresh defaults?
If that works, you can use the "divide and konqueror" method of finding
the problem, assuming you want to keep as much of the customization as
possible. =:^) Obviously something's corrupted in the kde config. Exit
kde again, blow away the defaults, and copy about half your .kde dir back
from the backup. Then try again. If it works, the corruption is in the
other half. If it doesn't, the corruption is in the half you moved. Now
you can move the good half in (double-checking it if you wish), and half
of the bad half, then try again. By such a "divide and konqueror" method
you can narrow it down to a directory, then a file in that directory.
Then inspect that file. Assuming it's not a text file with a bunch of
binary in it (corrupted), if you want to continue further, you can often
narrow it down to a single line in the file.
I've done this quite a number of times. In fact, the git distributed
version control system that Linus created (and others have continued
with) for managing the kernel includes a "git bisect" command just for
this purpose, to help automate the process, often narrowing down a
problem to a specific git commit, making it MUCH easier to fix. Doing it
manually (or even automatically when you have to reboot into the new
kernel to test) does take some time, and compound or complex issues don't
always break down cleanly with this method, but it's surprising how often
it works, and even when it doesn't work all the way down, it often
substantially narrows the search space.
If it doesn't work with a clean user kde config, but DOES work for root
(as you said), then the problem is likely to be permissions. You could
double-check by creating another, fully clean user (not just .kde
and .kdeglobals, but everything), and trying it. If it works,
permissions aren't so likely the issue; it's stuck in the other user
config. If it doesn't, then it's time to start looking around at the
various binary, library, and data dirs, for bad permissions on
something. Of course, if you had run kde as root before, then it
probably had a config there, that might have contained what the normal
config was missing, too. So you could double-check that it still works
if /its/ .kde dir and .kdeglobals are moved.
One other thing to check. Certainly kde3 and IIRC kde2 as well, used a
couple of communication sockets. If those got ripped out of /var/tmp or
/tmp or wherever they normally are, it's possible the permission issues
are there, not on the system libs/bins/config.
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