Checklist: Terminal Hangs When I Log In (Unix Power Tools, 3rd Edition) 5.6. Checklist: Terminal Hangs When I Log In If your terminal seems to "hang" (freeze, lock up) when you log in, here are some things to try: Have another user look at your shell's setup files (Section 3.3). There could be some obvious mistakes that you didn't catch. Log in to another account and use the su stucklogin command (if the stuck account uses Bourne-type shells) or the su -f stucklogin command (if the stuck account uses csh or tcsh). Change (cd ) to the home directory. Rename the account's setup files so the shell won't see them as you log in. (If you have superuser access (Section 1.18), you also can use it to rename the file.)[18] [18]Note that there is no user named stucklogin; you're expected to supply the actual login username as an argument to su. If you can log in after that, you know that the problem is with the account's setup files. Set shell debugging (Section 27.15) on the stuck account's setup files. From another account or as the superuser, start an editor and put the following line at the top of an sh-like setup file (such as .profile). It'll tell you whether .profile is being read at all and where it hangs: set -xv You'll see each line read from the .profile and the commands executed on the screen. If you don't see anything, then the shell probably didn't read .profile. Bash users would want to check .bashrc or .bash_profile. C-shell users should put this command at the top of .cshrc (or .tcshrc, for tcsh) instead: set echo verbose Note that on many Unix systems, the shell won't read its startup files if the files aren't owned by you. You might use ls -l (Section 50.2) to check. Look at the entry in the /etc/passwd file (Section 22.3) for this user. Be sure it has the correct number of fields (separated by :). Also, see if there's another user with the same login name. (If your system has commands like useradd, linuxconf, or vipw(8) and pwck(8), using them to edit and check the passwd file will avoid many of these problems, as those programs perform sanity checks on any modifications you make before taking them live.) Does your account use any directories remotely mounted (by NFS) (Section 1.21)? If the remote host or network is down and any command in your startup files (especially set path) tries to access those directories, the shell may hang there. To fix that problem, su to the account as explained earlier, and take the command or directory name out of your startup file. Or, if this problem happens a lot, the system administrator can mount an NFS filesystem "soft" (instead of "hard," the default) and limit the number of retrys. What looks like a "hang" might also be that you just aren't getting any output to the terminal, for some very weird reason. Then the set -xv wouldn't help you. In that case, try adding this line to the start of the .profile: exec > /tmp/sh.out.$$ 2>&1 If the Bourne shell starts reading .profile, it'll make a file in /tmp called sh.out.nnn with output from the commands and the shell's set -xv. There's no command like that for the C shell or tcsh. Here are a few more tips for dealing with stuck terminals. 5.6.1. Output Stopped? If your terminal has a HOLD SCREEN or SCROLL LOCK button, did you accidentally press it? Try pressing it and see if things start working again. If pressing the button once doesn't fix the problem, you should probably press it once more to undo the screen hold. Otherwise, you may lock up your session worse than it was before! Another way to stop output is by pressing CTRL-s. The way to restart stopped output is with CTRL-q -- try pressing that now. (Unlike a SCROLL LOCK button, though, if CTRL-q doesn't help, you don't need to undo it.) 5.6.2. Job Stopped? If you're at a shell prompt instead of in the program you thought you were running -- and if your Unix has job control -- you may have stopped a job. Try the jobs command (Section 23.1); if the job is stopped, restart it. 5.6.3. Program Waiting for Input? The program may be waiting for you to answer a question or type text to its standard input. WARNING: If the program you were running does something that's hard to undo -- like removing files -- don't try this step unless you've thought about it carefully. If your system has job control, you can find out by putting the job in the background with CTRL-z and bg. If the job was waiting for input, you'll see the message: [1] + Stopped (tty input) grep pat You can bring the job back into the foreground and answer its question, if you know what that question is. Otherwise, now that the job is stopped, you can kill it. See the following directions. On systems without job control, you might satisfy the program by pressing RETURN or some other key that the program is expecting, like y or n. You could also try pressing CTRL-d or whatever your "end of input" character is set to. That might log you out, though, unless you've set the ignoreeof variable. 5.6.4. Stalled Data Connection? Be sure that the wires haven't come loose. If you're using a modem and the modem has function lights, try pressing keys to see if the Send Data (SD) light flashes. If it does, your terminal is sending data to the host computer. If the Receive Data (RD) light flashes, the computer is sending data to your terminal. If you don't see anything, there might be something wrong on your terminal. If you're connected with rlogin or telnet or ssh (Section 1.21), the network to the remote computer might be down or really slow. Try opening another connection to the same remote host -- if you get a response like Connection timed out, you have two choices: Wait for your original connection to unfreeze. The connection may come back and let you keep working where you left off. Or the connection may end when rlogin, telnet, or ssh notices the network problem. Quit the session, and try again later. 5.6.5. Aborting Programs To abort a program, most users press CTRL-c. Your account may be set up to use a different interrupt character, such as DELETE. If this doesn't work, try CTRL-\ (CTRL-backslash). Under most circumstances, this will force the program to terminate. Otherwise, do the following: Log in at another terminal or window. Enter the command ps x, or, if that doesn't work, use ps -u yourname, where yourname is your Unix username. This displays a list of the programs you are running, something like this: % ps x PID TTY STAT TIME COMMAND 163 i26 I 0:41 -csh (csh) 8532 i26 TW 2:17 vi ts.ms 22202 i26 S 12:50 vi UNIXintro.ms 8963 pb R 0:00 ps -x 24077 pb S 0:05 -bin/csh (csh) % Search through this list to find the command that has backfired. Note the process identification (PID) number for this command. Enter the command kill PID (Section 24.12), where PID is the identification number from the previous step. If that doesn't work, try kill -1 PID to send a HUP signal. You can also try various other signals, including -2 or -15. If none of them work, you may need kill -9, but try the other kills first. If the Unix shell prompt (such as % or $) has appeared at your original terminal, things are probably back to normal. You may still have to take the terminal out of a strange mode though. If the shell prompt hasn't come back, find the shell associated with your terminal (identified by a tty number), and kill it. The command name for the C shell is csh. For the Bourne shell, it is sh. In most cases, this will destroy any other commands running from your terminal. Be sure to kill the shell on your own terminal, not the terminal you borrowed to enter these commands. The tty you borrowed is the one running ps; look at the previous example and check the TTY column. In this case, the borrowed terminal is TTY pb. Check ps to ensure that your shell has died. If it is still there, take more drastic action with the command kill -9PID. Run ps x or ps -u yourname again to be sure that all processes on the other tty have died. (In some cases, processes will remain.) If there are still processes on the other tty, kill them. At this point, you should be able to log in again from your own terminal. The ps (Section 24.5) command, which lists some or all of the programs you are running, also gives you useful information about the status of each program and the amount of CPU time it has consumed. --JP and SJC 5.5. Querying Your xterm Size: resize5.7. Find Out Terminal Settings with stty Copyright © 2003 O'Reilly & Associates. All rights reserved.