screen/keyboard frozen, jobs unaccessible, X problem?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
screen/keyboard frozen, jobs unaccessible, X problem?
Hi. Thanks for reading this post. I'm certainly a newby at dealing with anything resembling X-servers.
I am running a recent version of KDE on a 64 bit, multiprocessor machine. I guess it's a Suse 10 distro, probably a 2.4 kernel. Things have been running well for months. I have 3 emacs processes up, each which is the parent of a process of the statistical software 'R' and is doing something computationally intensive. These three processes fill the capacity of 3 of the 4 processors. I thought I could use a browser, but when I started Firefox, the screen froze. So much for putting something on the 4th processor.
The emacs-R processes have been running for over a week and have at least a week to go before they are finished. I would really like to regain control over them. I'm too afraid that I'll crash everything if I start trying things more or less at random.
The keyboard is also frozen, but the mouse pointer still moves. I have access to the machine via SSH. ps -A reveals that the emacs and R processes are still going.
Can I get the emacs processes and original display back? How do I get a usable GUI with the three emacs windows now? Do I need to restart KDE? the X-server? I'd love not to have to restart the machine and lose all that computation time.
Thank you for any help you can give. Sorry I don't know the actual X server or other details. If you tell me how to get any additional info, I'll definitely provide it!
Your question has had me thinking since I read it around lunchtime. It's easy enough to get out of X without a reboot (usually), but doing so will send HUP signals to your processes spawned there, killing them. Not what you want.
I've been toying with how to accomplish your wish. You need to somehow disassociate a running process from it's controlling terminal. You can do this with ioctl, but usually YOU are the process and YOU are trying to disassociate YOURSELF from a tty. However, you want to do this externally, initiated from a different process. Hmm. Even given root access I'm not sure how to do this.
My thoughts thus far are this: You can throw the process into the background using signals. Say the process you are interested in is pid 4956. You can externally get it into the background like this:
# kill -s STOP 4956
# kill -s CONT 4956
I'm musing on the possibility of doing an external open() on the controlling tty (as root) and then using ioctl() (TIOCNOTTY?) on the resulting file descriptor????? I have no idea if this would work. But if it does, you'd possibly have a process that should persist after you kill X.
Then maybe you could restart X, open a new terminal window, and somehow run some other ioctl() (TIOCSTTY?) to reassociate the process with a new tty?????
Maybe root could do some fiddling under /proc/<pid> to do all this magic in a different way?????
You've raised an interesting question that I've never thought about before. My brain is churning now. Probably futily, but still churning.
Yes, the emacs sessions were started with the command: nohup emacs & I would think that they are happily doing their thing in the background. The terminal that I used in KDE has been closed with 'exit'. I was able to terminate the firefox process from SSH, but this did not seem to affect the problem with X/KDE.
I'm always pleased when the problem is interesting. It would be great to be able to try something. Perhaps someone could think of a test situation (do: nohup emacs &, exit, a series of yet to be determined commands, restart X and KDE, reassociate the processes, go open a beer!).
I think the solution to this problem would be very useful for the community. X/KDE can crash, but any process started with nohup and & should be left untouched in the background (right?). How does one then get them back? It would be great, once there's a solution, to write a small script that one could execute remotely via SSH, supplying the relevant PIDs.
X/KDE can crash, but any process started with nohup and & should be left untouched in the background (right?).
That is correct. You never told us you used nohup in the first place. That greatly simplifies things! I was trying to find a way to force nohup-like operation AFTER-THE-FACT. You started it out that way in the beginning, so you should be all covered. You certainly should be able to kill X and restart it.
I just tested on my own system to illustrate this to you. I knew it would work, but since I know you REALLY don't want to accidently kill your current long-running processes, I thought I'd offer some proof to make you feel at ease. I use Gnome, so "gdm stop; gdm start" is one way I can kill X. You're using KDE so the specific commands you call will be different to kill the desktop manager. I don't know what KDE's equivalent to "gdm" is.