screen/keyboard frozen, jobs unaccessible, X problem?

pearman · 09-27-2006, 11:01 AM

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!

Best,

Peter

Mara · 09-27-2006, 04:05 PM

Important questions: were emacs sessions run under X? If so, restarting X/KDE will terminate emacs sessions.

Run ps, do you see Firefox process?

haertig · 09-27-2006, 04:57 PM

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:

Code:

# 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.

pearman · 09-28-2006, 02:52 AM

Mara, haertig,

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.

Please, more ideas!
Peter

haertig · 09-28-2006, 10:00 AM

Quote:

Originally Posted by pearman

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.

Good luck!

Code:

$ cat testprog
while [ 1 ]
do
        sleep 5
        date >> /tmp/testfile
done
$ chmod +x testprog
$ nohup ./testprog &
nohup: appending output to `nohup.out'
[1] 9462
$ ps j -p 9462
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
 8378  9462  9462  8378 pts/1     9495 S     1000   0:00 /bin/sh ./testprog
$ cat /tmp/testfile
Thu Sep 28 08:39:49 MDT 2006
Thu Sep 28 08:39:54 MDT 2006
Thu Sep 28 08:39:59 MDT 2006
Thu Sep 28 08:40:04 MDT 2006
$


-------------------------------------------------


<CTRL><ALT><F1> to get a new console window
su -
/etc/init.d/gdm stop
/etc/init.d/gdm start
logged back into Gnome desktop as a normal user


-------------------------------------------------


$ ps j -p 9462
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1  9462  9462  8378 ?           -1 S     1000   0:00 /bin/sh ./testprog
$ cat /tmp/testfile
Thu Sep 28 08:39:49 MDT 2006
Thu Sep 28 08:39:54 MDT 2006
Thu Sep 28 08:39:59 MDT 2006
Thu Sep 28 08:40:04 MDT 2006
Thu Sep 28 08:40:09 MDT 2006
Thu Sep 28 08:40:14 MDT 2006
Thu Sep 28 08:40:19 MDT 2006
Thu Sep 28 08:40:24 MDT 2006
Thu Sep 28 08:40:29 MDT 2006
Thu Sep 28 08:40:34 MDT 2006
Thu Sep 28 08:40:39 MDT 2006
Thu Sep 28 08:40:45 MDT 2006
Thu Sep 28 08:40:50 MDT 2006
Thu Sep 28 08:40:55 MDT 2006
Thu Sep 28 08:41:00 MDT 2006
Thu Sep 28 08:41:05 MDT 2006
Thu Sep 28 08:41:10 MDT 2006
Thu Sep 28 08:41:15 MDT 2006
Thu Sep 28 08:41:20 MDT 2006
Thu Sep 28 08:41:25 MDT 2006
Thu Sep 28 08:41:30 MDT 2006
Thu Sep 28 08:41:35 MDT 2006
Thu Sep 28 08:41:40 MDT 2006
Thu Sep 28 08:41:45 MDT 2006
Thu Sep 28 08:41:50 MDT 2006
Thu Sep 28 08:41:55 MDT 2006
Thu Sep 28 08:42:00 MDT 2006
$ date
Thu Sep 28 08:42:07 MDT 2006
$ kill 9462
$