|
|
|
Home > Help Files > Unix > Kill command
Kill Command
Interrupting or Aborting a Command or Process
The only way to abort a command or process while it is executing,
is to send it a certain kind of `signal'. A `signal' can be sent
in two ways: either with a single keystroke or with the `kill'
command. Interactive processes are normally aborted with a keys-
troke, however, if your terminal has frozen up (type "help dead-
terminal" for first aid methods) you may have to use the `kill'
command. The `kill' command is also needed for aborting `back-
grounded' or `submitted' processes (type "help submit" for an ex-
planation of these terms). These two methods are described in
the sections below.
Sometimes you may want to stop a command, such as `troff', `lpr',
`net', or `rcs', which is no longer executing but has activated a
`daemon'. The section at the end deals with killing daemons.
The single keystroke method
This is the normal method of aborting a process, and consists
simply of pressing RUB (type underscore "_" while holding down
the SHIFT key). Some terminals lack this key, but if your termi-
nal has any of the keys RUBOUT, DEL, DELETE, or ERASE, any one of
them will do the same thing as RUB. Each time one of these keys
is pressed, an `interrupt' signal is sent to the processes
currently running at the terminal, and generally causes them to
abort.
Some processes, however, are designed not to die upon receiving
an `interrupt' signal, but will capitulate upon receiving a
`quit' signal. A `quit' signal is sent by typing a control-\
(type "\" while holding down the CONTROL key). When a process is
killed in this way, the system deposits a file called `core' in
your directory. This file is created for a systems programmer's
use in tracing or debugging a process, and will probably not do
you much good (you can remove it by typing "rm -f core").
The `kill' command
Sometimes a process will ignore both of these keystroke-generated
signals. This will happen when a process has been `backgrounded'
or `submitted', in which case you can use the `kill' command to
abort it. It may also happen when your terminal is frozen in an
unresponsive state, in which case it may be necessary to kill
your login process (i.e. log you out) just to return your termi-
nal to a sensible state.
The `kill' command has the general form "kill -N PID", where you
replace `PID' with a process identification number and replace
`N' with a `signal' number. Usually, `N' will be `1' and the
PID, if you do not already know it, can be learned through the
`ps' command as described below. This command causes the speci-
fied signal to be sent to the specified process.
Signal numbers
Signal number `1', a `hangup' signal, is recommended because it
should kill the process and, if it is an editor, save the buffer.
Signal number `9', a `kill' signal, is the surest way to kill a
process and is recommended only as a last resort since it will
not save editor buffers.
You may wish to note that the interrupt and quit (keystroke) sig-
nals mentioned above can be sent to a process by replacing `N'
with `2' and `3', respectively. There are 15 different signals
that can be sent to a process via `kill'. Each of them conveys
slightly different information but generally causes death, whence
the name of the command.
Learning the PID
If you do not know the PID of a process, you can learn it by is-
suing a process status command, "ps". If a process is running at
a terminal that has become unresponsive or is displaying nothing
but garbage, its PID can be learned by logging in at another ter-
minal and typing "ps". This command sometimes takes quite a
while to complete, but eventually it will give you the PID and
associated terminal, or TTY, for all of your active processes.
The TTY name is used to identify which processes are running at
which terminal, in case you are logged-in more than once. The
command, "who", can be helpful in determining on which TTY the
doomed process is running.
An example
Suppose that your login name is `hal' and that the terminal you
are working on has just become unresponsive. After logging-in at
another terminal, a typical session could proceed as follows:
% ps x
PID TTY TIME CMD
7835 dz07 0:28 edit chap2.3
7809 dz07 0:19 -csh
106 bx112 0:05 -csh
% who
10 users @ Mon Dec 15 11:07:07 1980
annie 10:52 dz28 hal 10:33 dz07
appleyrd 10:11 bx167 hal 11:05 bx112
avante 08:38 dz41 op 06:12 dz24
dowallda 08:47 bx155 oriental 10:53 dz02
easia 07:53 dz26 panisse 10:09 dz29
% kill -1 7835
% kill -1 7809
The response from the `ps' command indicates that there are three
active processes, two on TTY `dz07' and one on `bx112'. The
`who' command indicates that `hal' is logged-in twice, where the
earlier login (at `dz07') is running the doomed processes. With
this information you might try to kill the `edit' process on
`dz07', as shown. If the unresponsive terminal does not revive,
it may be necessary to kill the login process on that terminal,
as in the last command shown.
Occasionally, a process will not succumb to any of these actions.
In this case a command of the form "kill -9 PID", where you sup-
ply the `PID', may work. Finally, if that does not work, contact
one of the Computing Services consultants in 262 Evans Hall,
642-0472 (type "help consult" to see the consulting schedule).
Killing backgrounded processes
When a process is `backgrounded' or `submitted', the shell prints
the PID (several PID's if "|" or ";" appear in the command) be-
fore returning with a prompt sign. If you remember the PID, you
may try to abort the process with "kill -1" as shown above.
If you have forgotten the PID of a submitted command, you must
learn it through `ps' as shown above. If you have forgotten the
PID of a backgrounded process, you can learn it through the C
shell's `wait' command (on VAX UNIX the command "jobs -l" is pre-
ferred). This command does nothing but wait for all backgrounded
processes to finish, at which time it returns with a normal
prompt; however, if RUB (type underscore "_" while holding down
the SHIFT key) is pressed, `wait' will print the PID's of all ac-
tive backgrounded processes, which will include any ones you
might have forgotten.
Killing daemons
A `daemon' spirits away copies of users' files and puts them on a
common queue for special processing at some later time. This
processing can be prevented if the appropriate file is removed
from the queue in time. For the four commands mentioned earlier,
`troff', `lpr', `net', and `rcs', the corresponding queues can be
displayed by typing "trq", "lpq", "netq", or "rcsq", from which
you can learn the position of your file in the queue and its
`internal' name. The `internal' file name is a string of digits
preceded by three letters, usually something like `cfa' or `dfa',
and is used after one of the commands `trrm', `lprm', `netrm', or
`rcsrm' to remove it. For example, to remove the file `cfa01903'
from the troff queue, you would type "trrm cfa01903". See the
UNIX Programmers' Manual for more about these commands.
SEE ALSO
Listed below are some commands that you can type to find out
about related topics.
help deadterminal
first aid for dead or frozen terminals
help submit
submitting or backgrounding a process
help consult
consulting hours
man kill killing (actually, sending signals to) a process
man ps process status
man who listing of users currently logged-in
man wait awaiting completion of backgrounded processes
man 4 tty
how terminals behave
man 5 core
what the `core' file is for
man rm removing stubborn files with `-f'
man 2 signal
complete list of sendable signals
|
|
© |