%
Refers to the most recent command put into the background (indicated by the plus sign when you type the jobs command). This action brings the command to the foreground.
%vi when there are two vi commands in the background results in an error message.)
If a command is stopped, you can start it running again in the background using the bg command. For example, refer back to job 5 from the jobs list in a previous example:
[5]+ Stopped nroff -man /usr/man4/*>/tmp/man4
Enter the following:
$ bg %5
After that, the job runs in the background. Its jobs entry appears as follows:
[5] Running nroff -man /usr/man4/*>/tmp/man4 &
Killing and Renicing Processes
Just as you can change the behavior of a process using graphical tools such as System Monitor (described earlier in this chapter), you can also use command-line tools to kill a process or change its CPU priority. The kill command can send a kill signal to any process to end it, assuming you have permission to do so. It can also send different signals to a process to otherwise change its behavior. The nice and renice commands can be used to set or change the processor priority of a process.
Killing processes with kill and killall
Although usually used for ending a running process, the kill and killall commands can actually be used to send any valid signal to a running process. Besides telling a process to end, a signal might tell a process to reread configuration files, pause (stop), or continue after being paused, just to name a few possibilities.
Signals are represented by both numbers and names. Signals that you might send most commonly from a command include SIGKILL (9), SIGTERM (15), and SIGHUP (1). The default signal is SIGTERM, which tries to terminate a process cleanly. To kill a process immediately, you can use SIGKILL. The SIGHUP signal can, depending on the program, tell a process to reread its configuration files. SIGSTOP pauses a process, while SIGCONT continues a stopped process.
Different processes respond to different signals. Processes cannot block SIGKILL and SIGSTOP signals, however. Table 6.1 shows examples of some signals (enter man 7 signal to read about other available signals).
Notice that there are multiple possible signal numbers for SIGCONT and SIGSTOP because different numbers are used in different computer architectures. For most x86 and Power architectures, use the middle value. The first value usually works for Alpha and SPARC, while the last one is for MIPS architecture.
Using kill to signal processes by PID
Using commands such as ps and top, you can find processes to which you want to send a signal. Then you can use the process ID of that process as an option to the kill command, along with the signal you want to send.
TABLE 6.1 Signals Available in Linux
Signal
|
Number
|
Description
|
SIGHUP
|
1
|
Hang-up detected on controlling terminal or death of controlling process. |
SIGINT
|
2
|
Interrupt from keyboard. |
SIGQUIT
|
3
|
Quit from keyboard. |
SIGABRT
|
6
|
Abort signal from abort(3). |
SIGKILL
|
9
|
Kill signal. |
SIGTERM
|
15
|
Termination signal. |
SIGCONT
|
19,18,25
|
Continue if stopped. |
SIGSTOP
|
17,19,23
|
Stop process. |
For example, you run the top command and see that the bigcommand process is consuming most of your processing power:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10432 chris 20 0 471m 121m 18m S 99.9 3.2 77:01.76 bigcommand
Here, the bigcommand process is consuming 99.9 percent of the CPU. You decide that you want to kill it so that other processes have a shot at the CPU. If you use the process ID of the running bigcommand process, here are some examples of the kill command that you can use to kill that process:
$ kill 10432 $ kill -15 10432 $ kill -SIGKILL 10432
The default signal sent by kill is 15 (SIGTERM), so the first two examples have exactly the same results. On occasion, a SIGTERM doesn't kill a process, so you may need a SIGKILL to kill it. Instead of SIGKILL, you can use –9 to get the same result.
Another useful signal is SIGHUP. If, for example, something on your GNOME desktop were corrupted, you could send the gnome-shell a SIGHUP signal to reread its configuration files and restart the desktop. If the process ID for gnome-shell
