Christopher Negus - Linux Bible

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 SIGHUPsignal can, depending on the program, tell a process to reread its configuration files. SIGSTOPpauses a process, while SIGCONTcontinues a stopped process.

Different processes respond to different signals. Processes cannot block SIGKILLand SIGSTOPsignals, however. Table 6.1shows examples of some signals (enter man 7 signalto read about other available signals).

Notice that there are multiple possible signal numbers for SIGCONTand SIGSTOPbecause 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 commands such as psand 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 killcommand, along with the signal you want to send.

TABLE 6.1 Signals Available in Linux

For example, you run the topcommand and see that the bigcommandprocess 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 bigcommandprocess 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 bigcommandprocess, here are some examples of the killcommand 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 SIGTERMdoesn't kill a process, so you may need a SIGKILLto kill it. Instead of SIGKILL, you can use –9to get the same result.

Another useful signal is SIGHUP. If, for example, something on your GNOME desktop were corrupted, you could send the gnome-shella SIGHUPsignal to reread its configuration files and restart the desktop. If the process ID for gnome-shellwere 1833, here are two ways you could send it a SIGHUPsignal:

# kill -1 1833 # killall -HUP gnome-shell

With the killallcommand, you can signal processes by name instead of by process ID. The advantage is that you don't have to look up the process ID of the process that you want to kill. The potential downside is that you can kill more processes than you mean to if you are not careful. (For example, typing killall bashmay kill a bunch of shells that you don't mean to kill.)

Like the killcommand, killalluses SIGTERM(signal 15) if you don't explicitly enter a signal number. Also as with kill, you can send any signal you like to the process you name with killall. For example, if you see a process called testmerunning on your system and you want to kill it, you can simply enter the following:

$ killall -9 testme

The killallcommand can be particularly useful if you want to kill a bunch of commands of the same name.

When the Linux kernel tries to decide which running processes get access to the CPUs on your system, one of the things it takes into account is the nice value set on the process. Every process running on your system has a nice value between –20 and 19. By default, the nice value is set to 0. Here are a few facts about nice values:

The lower the nice value, the more access to the CPUs the process has. In other words, the nicer a process is, the less CPU attention it gets. So, a –20 nice value gets more attention than a process with a 19 nice value.

A regular user can set nice values only from 0 to 19. No negative values are allowed. So a regular user can't ask for a value that gives a process more attention than most processes get by default.

A regular user can set the nice value higher, not lower. So, for example, if a user sets the nice value on a process to 10 and then later wants to set it back to 5, that action will fail. Likewise, any attempt to set a negative value will fail.

A regular user can set the nice value only on the user's own processes.

The root user can set the nice value on any process to any valid value, up or down.

You can use the nicecommand to run a command with a particular nice value. When a process is running, you can change the nice value using the renicecommand, along with the process ID of the process, as in the example that follows:

# nice -n +5 updatedb &

The updatedbcommand is used to generate the locate database manually by gathering names of files throughout the filesystem. In this case, I just wanted updatedbto run in the background ( &) and not interrupt work being done by other processes on the system. I ran the topcommand to make sure that the nice value was set properly:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20284 root 25 5 98.7m 932 644 D 2.7 0.0 0:00.96 updatedb

Notice that under the NIcolumn, the nice value is set to 5. Because the command was run as the root user, the root user can lower the nice value later by using the renicecommand. (Remember that a regular user can't reduce the nice value or ever set it to a negative number.) Here's how you would change the nice value for the updatedbcommand just run to –5:

# renice -n -5 20284

If you ran the topcommand again, you might notice that the updatedbcommand is now at or near the top of the list of processes consuming CPU time because you gave it priority to get more CPU attention.

You can use a feature like “nice” to give a single process more or less access to CPU time. Setting the nice value for one process, however, doesn't apply to child processes that a process might start up or any other related processes that are part of a larger service. In other words, “nice” doesn't limit the total amount of resources a particular user or application can consume from a Linux system.