The top 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. Linux tutorial 6-1 shows a top screen. The top 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 to root only. To do this, change the program’s permissions with the following command:

    [root@workbox /root]# chmod 0700 /usr/bin/top

Sending a Signal to a Process: kill

This program’s name is misleading: it doesn’t really kill processes. What it does do is send signals to running processes. The operating system, by default, supplies each process a standard set of signal handlers to deal with incoming signals. From a system administrator’s standpoint, the most important 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

The 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 terminal’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 modules). Most applications simply ignore the signal.

Security Issues

The power to terminate a process is obviously a very powerful one, making security precautions 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 of kill

Use this command to terminate process number 2059:

    [root@workbox /root]# kill 2059

For an almost guaranteed kill of process number 593, issue this command:

    [root@workbox /root]# kill -9 593

Type this to send the HUP signal to the init program (which is always PID 1):

    [root@workbox /root]# kill -1 1

Checking Your Processes

Let’s take a break from the theory of process management to see what processes are running on your Linux system. In this project, you’ll try to discover documentation and configuration information about active processes by using some of the commands described in this module.

Step by Step

1. From within X, check the most active processes on your Linux system. Use the top command from a terminal window to see what’s taking up the most CPU activity.

2. Note the most active process names and open another terminal window to see what information you can gather about those top processes. Use the which command to see where the executables are located. Use the man and info commands to determine whether there are command-line documents available for each of the most active processes.

3. Try to determine whether these programs have related files. Sometimes this information can be found in the SEE ALSO section of the man page for the program. Look especially for man section 5 references.

4. Try using the find command with the -name option and a regular expression to see if there are related configuration files in the /etc directory, spool or log files in the /var directory, or program files in the /usr, /sbin, or /bin directories.

5. Try to find configuration files that aren’t named like the program itself by performing a grep for the program’s name through the contents of the /etc directory.

6. Use the more command to view any configuration files brought to light by your efforts in steps 4 and 5.

7. Continue your investigation to the less-active programs by running the ps command and repeating steps 2–6.

Project Summary

Some of the programs that come with Red Hat Linux 8.0 have useful documentation in the /usr/share/doc directory, so that may be a good place to look for information about the programs that run on your system. However, even though README files and even web searches can often turn up exactly the information you need, being able to do a little sleuthing on your own can be invaluable in certain circumstances!