| Messed-up terminals are an occasional problem that system administrators have to deal with. When aterminal is hung (when it won't respond to any input) or seems to have gone crazy, here are some things to try that address the most common causes: If the user knows what she did last, try to undo it. For example, if she was experimenting with stty options, try a stty sane command. If the terminal doesn't respond at all, the user might have accidentally hit Ctrl-S, the pause key, the hold screen key, or something else that temporarily stops output. Try entering Ctrl-Q and then these other keys to see if things get going again. Check the terminal settings via its setup menu. In particular, is its baud rate set correctly? Try entering the reset command. If it doesn't work, try preceding and following it with a line feed (Ctrl-J if the terminal has no line feed key): ^Jreset^J Substituting stty sane in place of reset can also work. Running either command twice in succession is frequently necessary. If the user has turned the power off and back on, check other settings like the emulation mode. If the user hasn't cycled power, try this yourself; there are some conditions that only cycling the power will clear. Leave the terminal off for about 10 seconds to allow the internal capacitors to discharge completely. Next, go to another terminal and try to kill the program that was running on the hung terminal. It may be that the program and not the terminal is hung. Try a variety of signals in an attempt to neutralize the process TERM (kill's default), KILL, INT, QUIT, STOP use kill -l to list the available signals or consult /usr/include/sys/signal.h. Use the ps command with its -t option to limit the display to the desired terminal. -t takes the device name as its argument, in the same form in which it appears in the TTY column of ps's output. For example, the following command displays the processes for /dev/tty15: $ ps -t15 If nothing else works, trying killing the user's login shell. If the terminal doesn't come back after a few seconds, try cycling the power again. If cycling the power and killing everything in sight doesn't bring the terminal back, check the connections. Has the connector fallen off the back, for example? (In some cases, you'll want to check this first.) If a cable is loose, it will eventually fall due to gravity alone, even if the terminal hasn't moved an inch in months. For a new terminal, try checking these items: Is the terminal plugged into the correct RS-232 connector on the back of the system? It is easy to lose track of a cable between the terminal and the computer. Good record keeping and labeling will help eliminate this problem. Is the cable functioning properly? You can verify this by testing it on another cable or swapping it with a cable known to be working. Are the brightness and contrast settings turned all the way down? Verify that the display is in fact visible. Is the terminal port enabled and does it specify an appropriate way to call getty? Is the getty process running? Use ps piped to grep to count the number of getty processes and verify that the right number are present. Did you remember to signal init? Are you using the right kind of cable (null modem versus straight through)? If not, a command like the following will hang: # cat file > /dev/ttyn Don't forget to kill the process once you've verified that it is hung. NOTE  A device called a breakout box can be invaluable for troubleshooting difficult cable problems, especially if you are trying to build your own cables. You can usually pick one up at any electronics supply store for a reasonable price (under $50 U.S.). The breakout box includes LEDs that display which signals are actually active at any point. Better models also allow you to easily rearrange the wires in a cable or assert the proper voltage on individual pins for testing purposes. |
