KDE dead for only one user on multi-user system
I have a very serious (in my mind) and odd problem. I was trying to run an old program (soulride Jay_Peak) and when it went to full screen, everything locked up. I had no keyboard or mouse functions. I was unable to switch to a console. I performed a secure shell login from another machine and started killing processes of that user. Eventually the whole thing locked up hard and I was forced to perform the 0/1 test (reset). The machine came back up fine, until KDE login for the user that was attempting to run soulride. If I attempt to login to KDE I get one of two things, ksplash crashes or it hangs at the first step of KDE initialization (says something about "... interprocess communication" OWTTE). It will stay there for about 10 seconds and then crash. This only happens on one user out of 5 that are on this machine. I have tried deleting the .kde* and .DCOP* files/directories in this users home directory but still no luck. I have also renamed the .xinitrc file to bak.xinitrc but this had no affect either (not that I necessarily thought it would). Has this happened to anyone, and how do you fix it? Gnome also seems to be affected because this particular user cannot log into Gnome either. XFCE4 and FVWM work fine. All other users can log into any of the above mentioned desktop environments without issue. Any hints? Thanks, Darrell
On Thu, 04 Dec 2003 21:11:07 -0600, Darrell Cormier
I have a very serious (in my mind) and odd problem. I was trying to run an old program (soulride Jay_Peak) and when it went to full screen, everything locked up. I had no keyboard or mouse functions. I was unable to switch to a console.
... never heard of it, but i'd start looking for stray files. i'll bet money it somehow mucked with files in the ~ dir (as you might expect). i'd check for files that have a time-stamp change respective of the running of this program wait, you said you deleted the ~/.kde directory? hmmmm. now it sounds like a video oriented issue. what's the specs for this box? . -- /// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\ \\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" /// The United States Army; 194 years of proud service, unhampered by progress.
On Thursday 04 December 2003 9:11 pm, Darrell Cormier wrote:
I have a very serious (in my mind) and odd problem. I was trying to run snip<
This only happens on one user out of 5 that are on this machine. I have tried deleting the .kde* and .DCOP* files/directories in this users home directory but still no luck. I have also renamed the .xinitrc file to bak.xinitrc but this had no affect either (not that I necessarily thought it would). Has this happened to anyone, and how do you fix it?
Gnome also seems to be affected because this particular user cannot log into Gnome either. XFCE4 and FVWM work fine.
All other users can log into any of the above mentioned desktop environments without issue.
Any hints?
Thanks, Darrell
As root, go to the /tmp directory and delete all the directories and files associated with that userid. That may help. My clue is the "... interprocess communications" error you see. The .DCOP* directories are sym links to the same ones in /tmp anyway. There are others in /tmp that you would not have deleted. That is where the system stores the temporary lock files for most applications and desktop environment managers and this seems to be your issue with this userid. I don't believe that XFce4 and fvwm use these temporary lock files. Stan
Stan Glasoe wrote:
On Thursday 04 December 2003 9:11 pm, Darrell Cormier wrote:
<snip>
As root, go to the /tmp directory and delete all the directories and files associated with that userid. That may help. My clue is the "... interprocess communications" error you see. The .DCOP* directories are sym links to the same ones in /tmp anyway. There are others in /tmp that you would not have deleted. That is where the system stores the temporary lock files for most applications and desktop environment managers and this seems to be your issue with this userid. I don't believe that XFce4 and fvwm use these temporary lock files.
Stan
Thanks Stan, that did the trick. I was tempted to do that last night but was not sure what all used those /tmp files. Anyway, KDE is back. D.C.
participants (3)
-
Darrell Cormier -
mjt -
Stan Glasoe