unx19.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<H4 ALIGN="CENTER">

<CENTER><A ID="I18" NAME="I18">

<FONT SIZE=3><B>Job Control</B>

<BR></FONT></A></CENTER></H4>

<P>Some shells (C shell, csh, and Korn shell, ksh, are two) have increased ability to manipulate multiple processes from a single interactive shell. Although graphical interfaces have since added the ability to use multiple windows (each with it's own 
interactive shell) from one display, job control still provides a useful function.

<BR></P>

<P>First you need to understand the shell's concept of a job. A job is an executed command line. Recall the discussion of processes created during execution of a command. For many command lines (for example, pipelines of several commands), several 
processes are created in order to carry out the execution. The whole collection of processes that are created to carry out this command line belong to the same process group. By grouping the processes together into an identifiable unit, the shell allows 
you to perform operations on the entire job, giving you job control.

<BR></P>

<P>Job control allows you to do the following:

<BR></P>

<UL>

<LI>Move processes back and forth between the foreground and background

<BR>

<BR></LI>

<LI>Suspend and resume process execution

<BR>

<BR></LI></UL>

<P>Each job or process group has a controlling terminal. This is the terminal (or window) from which you executed the command. Your terminal can only have one foreground process (group) at a time. A shell that implements job control will move processes 
between the foreground and the background.

<BR></P>

<P>The details of job control use are covered in the section &quot;Job Control and Process Groups.&quot;

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I19" NAME="I19">

<FONT SIZE=4><B>Signaling Processes</B>

<BR></FONT></A></CENTER></H3>

<P>When a process is executing, UNIX provides a way to send a limited set of messages to this process: It sends a signal. UNIX defines a set of signals, each of which has a special meaning. Then the user, or other processes that are also executing, can 
send a specific signal to a process. This process may ignore some signals, and it may pay attention to others. As a nonprogramming user, you should know about the following subset of signals. The first group is important for processes, no matter what shell 

you are using. The second group applies if your shell supports job control.

<BR></P>

<P>General Process Control Signals

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>HUP</P>

<TD>

<P>Detection of terminal hangup or controlling process death</P>

<TR>

<TD>

<P>INT</P>

<TD>

<P>Interactive attention signal&#151;INTR control character generates this</P>

<TR>

<TD>

<P>KILL</P>

<TD>

<P>Termination&#151;process cannot ignore or block this</P>

<TR>

<TD>

<P>QUIT</P>

<TD>

<P>Interactive termination&#151;QUIT control character generates this</P>

<TR>

<TD>

<P>TERM</P>

<TD>

<P>Termination&#151;process may ignore or block this</P></TABLE>

<P>Job Control Process Control Signals

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>CONT</P>

<TD>

<P>Continue a stopped process&#151;process cannot ignore or block this</P>

<TR>

<TD>

<P>STOP</P>

<TD>

<P>Stop a process&#151;process cannot ignore or block this</P>

<TR>

<TD>

<P>TSTP</P>

<TD>

<P>Interactive stop&#151;SUSP control character generates this</P>

<TR>

<TD>

<P>TTIN</P>

<TD>

<P>Background job attempted a read&#151;process group is suspended</P>

<TR>

<TD>

<P>TTOU</P>

<TD>

<P>Background job attempted a write&#151;process group is suspended</P></TABLE>

<P>The default action for all the general process control signals is abnormal process termination. A process can choose to ignore all signals except the KILL signal. There is no way for you to tell what processes are ignoring what signals. But if you need 

to terminate a process, the KILL signal cannot be ignored and can be used as a last resort when attempting to terminate a process.

<BR></P>

<P>The default action for the job control process control signals is suspending process execution, except for the CONT signal which defaults to resuming process execution. Once again, a process may choose to ignore most of these signals. The CONT signal 
cannot be ignored, so you can always continue a suspended process. The STOP signal will always suspend a process because it cannot be ignored.

<BR></P>

<P>Except for KILL and STOP, a process may catch a signal. This means that it can accept the signal and do something other than the default action. For example, a process may choose to catch a TERM signal, do some special processing, and finally either 
terminate or continue as it wishes. Catching a signal allows the process to decide which action to take. If the process does not catch a signal and is not ignoring the signal, the default action results.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I20" NAME="I20">

<FONT SIZE=4><B>Killing Processes</B>

<BR></FONT></A></CENTER></H3>

<P>At some time or other, you will run a command and subsequently find out that you need to terminate it. You may have entered the wrong command, you may have entered the right command but at the wrong time, or you may be stuck in a program and can't 
figure out how to exit.

<BR></P>

<P>If you want to terminate your foreground process, the quickest thing to try is your interrupt control character. This is usually set to Ctrl+C, but make sure by looking at your stty -a output. The interrupt control character sends an INT signal to the 
process. It is possible for a program to ignore the INT signal, so this does not always terminate the process. A second alternative is to use your quit character (often Ctrl +\, set using stty quit <I>char</I>), which will send a QUIT signal. A process can 

ignore the QUIT signal. If your shell supports job control (C or Korn shells), you can suspend the process and then use the kill command. Once again, your process can ignore the suspend request. If you don't have job control or if none of these attempts 
work, you need to find another window, terminal, or screen where you can access your computer. From this other shell you can use the ps command along with the kill command to terminate the process. To terminate a process that is executing in the 
background, you can use the shell that is in the foreground on your terminal.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I21" NAME="I21">

<FONT SIZE=3><B>The </B><B><I>kill</I></B><B> Command</B>

<BR></FONT></A></CENTER></H4>

<P>The kill command is not as nasty as it sounds. It is the way that you can send a signal to an executing process (see the section &quot;Signaling a Process&quot;). A common use of the kill command is to terminate a process, but it can also be used to 
suspend or continue a process.

<BR></P>

<P>To send a signal to a process, you must either be the owner of the process (that is, it was started via one of your shells) or you must be logged in as root.

<BR></P>

<P>See the section &quot;Job Control and Process Groups&quot; for information on how to use special features of the kill command for managing jobs.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I22" NAME="I22">

<FONT SIZE=3><B>Finding What to Kill Using </B><B><I>ps</I></B>

<BR></FONT></A></CENTER></H4>

<P>To send a signal to a process via the kill command, you need to somehow identify the particular process. Two commands can help you with this: the ps command and the jobs command. All UNIX systems support some version of the ps command, but the jobs 
command is found in job control shells only. (See the section &quot;Job Control and Process Groups&quot; for details on job control and the jobs command.)

<BR></P>

<P>The ps command shows system process information for your computer. The processes listed can be owned by you or other users, depending on the options you specify on the ps command. Normally, if you want to terminate a process, you are the owner. It is 
possible for the superuser (root) to terminate any processes, but non-root users may only terminate their own processes. This helps secure a system from mistakes as well as from abuse.

<BR></P>

<P>Terminating a process can be a three-step process: first you should check the list of processes with ps. See the section &quot;Monitoring Processes&quot; if you're not sure how to do this. The output of ps should contain the process identifier of each 
process. Make sure you look for the PID column and not the PPID column. The PPID is the process ID for the parent process. Terminating the parent process could cause many other processes to terminate as well.

<BR></P>

<P>Second, you can send a signal to the process via the kill command. The kill command takes the PID as one argument; this identifies which process you want to terminate. The kill command also takes an optional argument, which is the signal you wish to 
send. The default signal (if you do not specify one) is the TERM signal. There are several signals that all attempt to terminate a process. Whichever one you choose, you may specify it by its name (for example, TERM) or by a number. The name is preferable 

because the signal names are standardized. The numbers may vary from system to system. To terminate a process with PID 2345, you might try kill -HUP 2345. This sends the HUP signal to process 2345.

<BR></P>

<P>Third, you should check the process list to see if the process terminated. Remember that processes can ignore most signals. If you specified a signal that the process ignored, the process will continue to execute. If this happens, try again with a 
different signal.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B> If you have a CPU-intensive job running in the background and you want to get some work done without killing the job, try using kill -STOP <I>PID</I>. This will force the job to be suspended, freeing 
up CPU time for your more immediate tasks. When you are ready for the job to run again, try kill -CONT <I>PID</I>.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I23" NAME="I23">

<FONT SIZE=3><B>Determining Which Signal to Send</B>

<BR></FONT></A></CENTER></H5>

<P>The sure way to make a process terminate is to send it the KILL signal. So why not just send this signal and be done with it? Well, the KILL signal is important as a last resort, but it is not a very clean way to cause process termination. A process 
cannot ignore or catch the KILL signal, so it has no chance to terminate gracefully. If a process is allowed to catch the incoming signal, it has an opportunity to do some cleaning up or other processing prior to termination. 

<BR></P>

<P>Try starting with the TERM signal. If your interrupt control character did not work, the INT signal probably won't either, but it is probably a reasonable thing to try next anyway. A common signal that many processes catch and then cleanly terminate is 

the HUP signal, so trying HUP next is a good idea. If you would like a core image of the process (for use with a debugging tool), the QUIT signal causes this to happen. If your process isn't exiting at this point, it might be nice to have the core image 
for the application developer to do debugging. If none of these signals caused the process to terminate, you can fall back on the KILL signal; the process cannot catch or ignore this signal.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B>  If your process is hung up waiting for certain events (such as a network file server that is not responding), not even kill will have any visible effect immediately. As long as your process isn't 
using CPU time, you can probably stop worrying about it. The hung process will abort if the event ever occurs (for example, the file server responds or the request times out), but it might not go away until the next time you reboot.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>If you need a list of the available signals, the -l option to the kill command will display this list. You can also check the kill and signalf man pages for descriptions of each signal. The signals described in this section are the standard signals, but 

some systems may have additional supported signals. Always check the manual for your system to be sure.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I24" NAME="I24">

<FONT SIZE=3><B>The </B><B><I>dokill</I></B><B> Script An Example</B>

<BR></FONT></A></CENTER></H4>

<P>Look at the dokill script as an example of how to kill a process reasonably and reliably:

<BR></P>

<PRE>#!/bin/sh

# TERM, HUP and INT could possibly come in a different order

# TERM is first because it is what kill does by default

# INT is next since it is a typical way to let users quit a program

# HUP is next since many programs will make a recovery file

# QUIT is next since it can be caught and often generates a core dump

# KILL is the last resort since it can't be caught, blocked or ignored

for sig in TERM INT HUP QUIT KILL

do

        dosleep=0

        for pid in $*

        do

                # kill -0 checks if the process still exists

                if kill -0 $pid

                then

                        # Attempt to kill the process using the current signal

                        kill -$sig $pid

                        dosleep=1

                fi

        done

        # Here we sleep if we tried to kill anything.

        # This gives the process(es) a chance to gracefully exit

        # before dokill escalates to the next signal

        if [ $dosleep -eq 1 ]

        then

                sleep 1

        fi

done</PRE>

<P>This script uses the list of signals suggested in the section &quot;Determining Which Signal to Send.&quot; For each signal in the suggested list, dokill sends the signal to any processes remaining in its list of processes to kill. After sending a 
signal, dokill sleeps for one second to give the other processes a chance to catch the signal and shut down cleanly. The last signal in the list is KILL and will shut down any process that is not blocked, waiting for a high-priority kernel event. If kill 
-KILL does not shut down your process, you may have a kernel problem. Check your system documentation and the WCHAN field of ps to find out which event blocked the process.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I25" NAME="I25">

<FONT SIZE=4><B>Logging Out with Background Processes</B>

<BR></FONT></A></CENTER></H3>

<P>After you start using executing processes in the background, you may forget or lose track of what processes you have running. You can always check on your processes by using the ps command (see the section &quot;Monitoring Processes&quot;). 
Occasionally, you will try to exit from your shell when you have processes running in the background. By default, UNIX tries to terminate any background or stopped jobs you have when you log out. UNIX does this by sending a HUP signal to all of your child 

processes.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B>  As a safeguard, job control shells (such as csh and ksh) issue a warning instead of allowing you to log out. The message will be similar to &quot;You have stopped (running) jobs.&quot; If you