ss (02/14/83)
Today my terminal got hung. I had been running vi under ucb/mail - when I went to exit from vi I got the # lines in filex message, but the cursor stayed at the end of this message, and no prompt appeared. I did the usual things, control-c'd control-z'd, reset the terminal, etc. I rushed over to another terminal and looked at my processes - the current one was in "I" state. I sent some signals to that process, and figured that something would happen - I was wrong. I sent some signals to all the other processes attached to that terminal and finally got a getty running - but still nothing when I typed anything at the keyboard. I went to the other terminal again and tried some more things - sent some more signals. Finally I got to the state where the only thing attached to that terminal was an <exiting> status. This process I was unable to kill, even with a 9 (KILL) signal, one which is suppossed to be non-catchable(?). Anyway, this is all kind of vague, but does anyone recognize this situation? (Oh - I had to reboot the system to get my terminal back!) Thanks, Sid Shapiro -- decvax!wivax!ss -- Wang Institute -- (617)649-9731 ss.Wang-Inst@UDel-Relay
puder (02/15/83)
<exiting> processes are not responsive to signals because they are not there. They show up in ps output because some action is still pending regarding them. Examples of this are: output from the process that is still buffered, parent processes that have not yet been signalled that the <exiting> process has exited. The output buffer can be cleared by doing (stty raw; stty -raw) > /dev/ttyXX (at least one of entering/leaving raw mode clears the tty buffer). Others reading this can probably tell of other details. Karl Puder burdvax!puder SDC-aBC, R & D Paoli, Pa. (215)648-7555
ken (02/16/83)
Terminal hung up on a process that is <exiting>? Try killing its parent and other ancestors, all the way up the the grandfather shell if you have to. A new login will appear, and you can start up again without rebooting the system. Unfortunately, the <exiting> task will probably hang around until the system is rebooted, but it is harmless. After the editor (vi) crashes, a carriage return will not work to terminate an input line, and a line feed (LF) must be used instead. tset (LF) will usually fix up weird states of the terminal.