5.6. Checklist: Terminal Hangs When I Log In
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
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
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
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
C-shell users should put this command
at the top of .cshrc (or .tcshrc, for
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.)
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
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
There's no command like that for the C shell or
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
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.
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:
 + 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
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
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
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
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
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
--JP and SJC
Copyright © 2003 O'Reilly & Associates. All rights reserved.