Console Based Monitoring

Those familiar with UNIX system administration already know about the ps or process display command commonly found on most flavors of UNIX. Because Linux is closely related to UNIX, it also benefits from this command and enables you to quickly see the current running processes on the system as well as who owns them and how resource-hungry they are.

Although the Linux kernel has its own distinct architecture and memory management, it also benefits from enhanced use of the /proc file system, the virtual file system found on many UNIX flavors. Through the /proc file system, you can directly communicate with the kernel to get a deep view of what is currently happening. Developers tend to use the /proc file system as a way of getting information out from the kernel and for their programs to manipulate it into more human-readable formats. The /proc file system is beyond the scope of this book; but if you want to get a better idea of what it contains, head on over to http://en.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html for an excellent and in-depth guide.

Processes can also be controlled at the command line, which is important because you might sometimes have only a command-line interface. Whenever an application or command is launched, either from the command line or by clicking on an icon, the process that comes from the kernel is assigned an identification number called a process ID, or PID for short. This number is shown in the shell if the program is launched via the command line:

In this example, the xosview client has been launched in the background, and the (bash) shell reported a shell job number ([1] in this case). A job number or job control is a shell-specific feature that allows a different form of process control, such as sending or suspending programs to the background and retrieving background jobs to the foreground. (See your shell's man pages for more information if you are not using bash.)

The second number displayed (59i8 in this example) represents the process ID. You can get a quick list of your processes by using the ps command like this:

PID TTY TIME

CMD bash

55i0 pts/0 00:00:00 59i8 pts/0 00:00:00 5932 pts/0 00:00:00

ps xosview

Note that not all output from the display is shown here. As you can see, however, the output includes the process ID, abbreviated as pid, along with other information, such as the name of the running program. As with any UNIX command, many options are available; the proc man page has a full list. A most useful option is aux, which provides a friendly list of all the processes. You should also know that ps works not by polling memory, but through the interrogation of the Linux /proc or process file system. (ps is one of the interfaces mentioned at the beginning of this section.)

The /proc directory contains quite a few filessome of which include constantly updated hardware information (such as battery power levels and so on). Linux administrators often pipe the output of ps tHRough a member of the grep family of commands to display information about a specific program, perhaps like this:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND andrew 59i8 0.3 i.i 2940 i4i2 pts/0 S i4:04 0:00 xosview

This example returns the owner (the user who launched the program) and the PID, along with other information, such as the percentage of CPU and memory usage, size of the command (code, data, and stack), time (or date) the command was launched, and the name of the command. Processes can also be queried by PID like this:

You can use the PID to stop a running process by using the shell's built-in kill command. This command asks the kernel to stop a running process and reclaim system memory. For example, to stop the xosview client in the example, use the kill command like this:

$ kill 5918

After you press Enter (or perhaps press Enter again), the shell might report

[i]+ Terminated xosview

PID TTY 59i8 pts/0

STAT S

TIME COMMAND 0:00 xosview

Note that users can kill only their own processes, but root can kill them all. Controlling any other running process requires root permission, which should be used judiciously (especially when forcing a kill by using the -9 option); by inadvertently killing the wrong process through a typo in the command, you could bring down an active system.

Was this article helpful?

0 0

Post a comment