Kind of a random question, but yesterday I ran into some instability with KDE3 (and everyone is saying that it is rocksolid stable, but I digress). My kded was maxing out my processor with no signs of letting go, and I was unable to change windows or anything within KDE (although the top window I could still use, which was my IM message window from pidgin). So I Ctrl+Alt+F6 and log in to manually kill the process. After that I hop back into X, and things were still really screwed up. Processor was still maxed and so I hop back to the console and run top, which then shows that kicker is maxing out the processor now. So I kill that. I then jump back to kde and find that my kicker panel is gone (which is understandable). So I then try to start it from the getty only to say it couldn't connect to the X session. It has been a while since I have launched apps outside of X, and I was wondering how to do it properly.

I have since just killed X and started it back up and have been running fine since. But this is more for the "info for the future" place in my brain.

So when you are in a getty how do you start an application within the x session? I tried kicker :0, but it complained that it wasn't a valid argument.

When you're in a console, your $DISPLAY variable isn't set (among a few other things), it is a different process altogether, a terminal knows next to nothing about X. (never tried, but you could try to run these commands from the getty (but you mus tbe the same user!): (note $ represents a prompt)
$ export DISPLAY=:0
$ kicker &

Even rocksolid stable things can use up max cpu due to some strange combination of things, but I disgress along ;-)

Next time such a thing happens, you can kill X by pressing ctrl-alt-backspace while in your X session, KDM should come back up and let you log back in. Naturally, in that case your running X applications have died and will have lost their unsaved data.

Another thing you could've done was starting an xterm (I guess you could still press F2 and type xterm or xrvt or whatever xterm you prefer) while in your (very slow) kde session.

HTH

1 members found this post helpful.

Yeah, I know that weird combos can make programs freak out, I was just commenting about that due to the flames about how stable KDE3 is vs KDE4. Just thought it was kinda funny.

About exporting the display symbol, I will have to try that next time. As far as ending the X session, I actually ended up doing the Ctrl+Alt+Backspace, but I was looking to recover KDE without shutting it down. And I start with runlevel 3, so KDM doesn't apply to me.

As far as starting the xterm, what do you mean by pressing F2? I just tried it and it doesn't do anything. Is it supposed to bring up a run dialog?

But thanks for the info.

In fluxbox & xfce, alt-f2 brings up the 'run' dialog - perhaps it's somewhat universal...?

cheers,

1 members found this post helpful.

Well, I just tested in KDE 3.5.9 and it didn't work, but that is good info for when I use those DE's. Thanks.

It does in KDE 3.5.7 and I feel sure it should in 3.5.9. Look in Control Centre->Regional & Accessability->Keyboard Shortcuts. It should be there under Desktop->Run Command.

1 members found this post helpful.

It should work in KDE, and indeed - I somehow missed the alt in alt-F2. Sorry for that inconvenience. It is not unlikely that this is catched and ran by ... kicker however.
That is - I think, the core of your problem: killing kicker and restarting it, is that deep into the core of KDE that it's pretty much as "helpful" as killing Explorer in Windows. See it as one of the designflaws of KDE 3.

Kicker hanging /eating cpu because another application is misbehaving is another option to certain misbehaviours. I'd rather restart X than go the tedious road of killing and restarting parts that are hard to investigate how they are misbehaving. However, there are circumstances where this is necessary. The world of killing processes is not one that is easy to get into, things not always are what they appear at 1st sight.

it does, but I think it is caught by kicker ;-) and if kicker is dead, it's probably not caught at all.

Well, that probably explains it. A couple of Slack versions back (could've been when I first moved over to Slack with 10.2), I had set up a key command for the Win+R to open the run dialog (since I was so used to it with windows). Since then I don't even use it anymore, because I have a run command in my kicker, but I guess it carried over in my configs. This is one reason why when I finally move to Slack 13, I will be starting fresh and only refering to old configs. I will not copy anything over.

As far as the killing and restarting processes, I realize this can be a very tedious process, but I was willing to try it for two reasons. One, there was some stuff open that I didn't want to lose. It wasn't anything major, but I like to go through everything and make sure that everything is saved properly before I shutdown/logoff. Two, I wanted to go through the learning experience of what can and can't be done. At one point with XP I was able to shut down enough services that the laptop was running fully functional on 11 processes on boot. In doing that, I also found what processes can't be shut down. I am looking to get knowledge like that within linux/slackware, which can only happen by experimenting. I am sure there are guides out there that can help, but there is nothing like learning something after you screw something else up. You tend to never forget those lessons.

But thanks for the input everyone. This is why slack rocks.