|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 7: Displays and Emulations |
|
||||||||||||||||||||||||||||||||||||
|
After walking up to an ASCII terminal to do some work, you might find that the screen is blank and won't accept any input from the keyboard. You can try several things to get back to a login prompt or a shell.
In many cases, if the problem was reported by a user, it might be a loose cable. Many users overlook a loose cable even if you ask them to check the cables. When some users do look at the cables they don't look at the proper cables that deal with the problem at hand. If you work remotely, and nothing else works to get the terminal working, you must go and check the cables. You might even need to replace cables if they have gone bad. Be prepared with spares. Users sometimes kick a cable and snap the connector, roll a heavy object over a cable, or even steal the cable off the back of the terminal for some other use without telling anyone.
If you try typing on the keyboard three times and realize that you've struck the keyboard twice extra for no reason, you probably will try striking the keyboard three more times again out of habit. After you finally convince yourself that the keyboard is not accepting any input, check whether the terminal is locked. Here are three ways that a terminal can become locked.
Ctrl+Q and Ctrl+S --When a user types Ctrl+S, the text on the terminal stops. If this keystroke is made, the only way to release the keyboard is to use a Ctrl+Q.
Scroll Lock and Hold Screen --Often, a user or even you hits the Scroll Lock key or the Hold Screen key by accident. Pressing the key again should release the keyboard.
Proprietary Locks --Some ASCII terminal manufacturers have proprietary keystrokes and passwords to lock and unlock their terminals. Check the manufacturer's manuals or Web site or the setup menus on the terminal for more information on dealing with these special features.
Flavor: AT&T, BSD
Shells: All
Syntax:
kill PID
The console port for an ASCII terminal is controlled by a daemon called a getty. If this is killed, a new one restarts and resets the serial connection to the console port, or ASCII terminal. The getty sets the terminal type, modes , speed, and line discipline. In UNIX, when this daemon is started it is controlled by the init process. When init starts up it references the /etc/inittab file or /etc/ttytab on older BSD systems for all its configurations. An entry consists of the following fields: an ID, run state, action, and process.
t1:23:respawn:/sbin/getty ttyd1 co_9600
Because the getty daemon is controlled by the init process you can merely kill the getty process and init restarts a new getty automatically. This is because of the third field in the inittab entry, that says to respawn the daemon if it exits for any reason.
|
Warning - Do not kill the init process, because you can cause more harm then good depending on the settings on the configuration table. |
rocket 6# ps -ef | grep getty root 20665 1 0 Dec 05 ttyd1 0:00 /sbin/getty ttyd1 co_9600
rocket 7# kill 20665 rocket 8# ps -ef | grep getty root 3463 1 0 01:31:14 ttyd1 0:00 /sbin/getty ttyd1 co_9600
This example can be applied only to a system that has multiple terminals attached, X terminals, diskless clients, or a network connection for remote access to kill the daemon.
You might think that the simple solution is to power cycle the ASCII terminal. There can be severe repercussions by doing this. Some of the new servers and systems out on the market today can sense a loss of power to the terminal. When power is restored to the terminal you can find yourself sitting at the system's PROM level or in a maintenance mode. Simply put, the system goes down hard.
Test this on your particular system during a scheduled outage or when the terminal is first attached to the system. It doesn't happen on all systems, but there are a select few that it does happen to.
Different things can happen to the emulation and keyboard without notice or by accident when a user works on an ASCII terminal.
Executing the cat command on a directory, issuing a grep on a binary file, dropping the keyboard, unplugging a cable, or hitting the wrong key by mistake can all cause an ASCII terminal to experience some type of problem. If none of these occurs and there is still a problem, keep your eye out for user error.
A frantic call came in from a user at a remote site 70 miles away. The terminal quit working! There was power to the monitor and to the keyboard, but no output appeared on the terminal. Of course, my first gut feeling was that the cable was unplugged. The system engineer (SE) from the manufacturer insisted that it was a cable issue. The SE was reassured that the users had checked out all the hardware and cables. The SE arrived at the site first and wasn't too happy. Not only was he dragged out of bed to be there at 3:30 a.m., but he found the problem was a loose cable that had been pulled out when the terminal was moved. The users checked the cable only where it connected to the terminal and not where it connected to the computer.
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 7: Displays and Emulations |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.