Show an Interactive List of Processes: top

Show an Interactive List of Processes: top
Thetop command is an interactive version of ps. Instead of giving a static view of what
is going on, top refreshes the screen with a list of processes every two to three seconds
(user-adjustable). From this list, you can reprioritize processes or kill them. Figure 5-1
shows a top screen.
Thetop program’s main disadvantage is that it’s a CPU hog. On a congested system,
this program tends to complicate system management issues. Users start running top
to see what’s going on, only to find several other people running the program as well,
slowing down the system even more.
By default, top is shipped so that everyone can use it. You may find it prudent,
depending on your environment, to restrict top’s use to root only. To do this, as root,
change the program’s permissions with the following command:
[root@fedora-serverA ~]# chmod 0700 `which top`
Send a Signal to a Process: kill
This program’s name is misleading: It doesn’t really kill processes. What it does is send
signals to running processes. The operating system, by default, supplies each process
with a standard set of signal handlers to deal with incoming signals. From a system
administrator’s standpoint, the most common handlers are for signals number 9 and
15, kill process and terminate process, respectively. When kill is invoked, it requires
at least one parameter: the process identification number (PID) as derived from the ps
command. When passed only the PID, kill sends signal 15. Some programs intercept
this signal and perform a number of actions so that they can shut down cleanly. Others
just stop running in their tracks. Either way, kill isn’t a guaranteed method for making
a process stop.
Signals
An optional parameter available for kill is -n, where the n represents a signal number.
As system administrators, we are most interested in the signals 9 (kill) and 1 (hang up).
The kill signal, 9, is the impolite way of stopping a process. Rather than asking a
process to stop, the operating system simply kills the process. The only time this will fail
is when the process is in the middle of a system call (such as a request to open a file), in
which case the process will die once it returns from the system call.
The hang-up signal, 1, is a bit of a throwback to the VT100 terminal days of UNIX.
When a user’s terminal connection dropped in the middle of a session, all of that termi-
nal’s running processes would receive a hang-up signal (often called a SIGHUP or HUP).
This gave the processes an opportunity to perform a clean shutdown or, in the case of
background processes, to ignore the signal. These days, a HUP is used to tell certain
server applications to go and reread their configuration files (you’ll see this in action in
several of the later chapters). Most applications simply ignore the signal.
Security Issues
The ability to terminate a process is obviously a powerful one, making security pre-
cautions important. Users may kill only processes they have permission to kill. If non-
root users attempt to send signals to processes other than their own, error messages are
returned. The root user is the exception to this limitation; root may send signals to all
processes in the system. Of course, this means root needs to exercise great care when
using the kill command.
Examples Using the kill Command
Use this command to terminate a process with PID number 205989:
[root@fedora-serverA ~]# kill 205989
For an almost-guaranteed kill of process number 593999, issue this command:
[root@fedora-serverA ~]# kill -9 593999
Type the following to send the HUP signal to the init program (which is always
PID 1):
[root@fedora-serverA ~]# kill -SIGHUP 1
This command is the same as typing