[kde-linux] KDE suddenly refuses to start

[Duncan]

"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