Thus far, you haven't had to worry much about which processes were running and what they were called. At most, you've used the jobs command to manage a list of jobs started from a single shell's command line. Sometimes, however, you need to list and modify running processes on a systemwide basis. Using the command line, you can list all the running processes on a system, kill processes by their process ID number, or reprioritize processes relative to other processes in the system so that you can control processor time allocation on a busy system. Because normal users can list all processes but have access to modify only their own processes, management of systemwide processes is often done as the root user so that all processes can be managed and/or modified. Listing Running ProcessesThe ps command lists processes that are currently running. Because a given Linux system might have a very long list of running processes, and because so much data can be displayed about the properties and resources of each process, the ps command supports a wide range and variety of options to modify its behavior. The simplest way to call ps is without arguments. Whether called by root or by a normal user, calling the command this way has the effect of listing all the processes owned by the current login with information in several columns: [you@workstation20 ~]$ ps PID TTY TIME CMD 971 pts/0 00:00:00 bash 1028 pts/0 00:00:00 ps [you@workstation20 ~]$ This basic ps listing is very small because it includes only those processes owned by the user who has called ps and that were started from the command line. This listing indicates that only two processes have been started by you at the command line: the bash program (the login shell, which provides the command line) and the ps program, which lists itself because it is running, actively displaying the list of processes owned by the user. There are several columns of information in the ps output:
The basic ps listing can be helpful when you're logged in as a normal user and simply want to manage your own processes. However, from a system administration perspective, it is often important to get information about all processes currently running on a Linux system or to get extended information about the processes being listed. This way, you can monitor the behavior of multiple users or server processes as the system functions on a day-to-day basis. By supplying options or arguments to the ps command, you can change the types of processes that are listed and the information that is displayed about each process. The most common and useful ps options are shown in Table 28.1.
You can mix and match the ps options listed in Table 28.1 on the command line with relative impunity. Perhaps the two most common ways to call the ps command are with the -e and -f options or with the a and x options, in the following formats: ps -ef ps ax Both of these commands have similar effects: They display a listing of processes owned by all users, including those processes not launched from a controlling terminal. These two options enable the root user (or any other user, for that matter) to get a quick listing of all running processes on the system.
Adjusting Process PriorityThe root user can adjust the priority of any running process upward (less CPU time) or downward (more CPU time) using the renice command and the process ID number of the related process. This way, the administrator can ensure that critical processes on an overloaded system get as much CPU time as possible, sometimes at the expense of other processes. To use the renice command, call it as follows: renice priority pid Replace priority with the desired priority, from -20 (highest priority) to +19 (lowest priority). Replace pid with the process ID number of the process whose priority you want to change. For example, to maximize the priority of process number 664 while minimizing the priority of process 702, you enter the following: [root@workstation20 you]# renice -20 664 664: old priority 0, new priority -20 [root@workstation20 you]# renice +19 702 702: old priority 0, new priority 19 [root@workstation20 you]# You can see the effects of renice operations in the output of the ps command as well because of the appearance of N (decreased priority) or < (increased priority) in the STAT column, as follows: PID TTY STAT TIME COMMAND [...] 664 ? S< 0:00 /usr/sbin/sshd 678 ? S 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid 702 ? SN 0:00 sendmail: accepting connections 712 ? S 0:00 sendmail: Queue runner@01:00:00 for /var/spool/client [...] This fragment shows process 664 with a status of S<, which indicates a sleeping process with increased priority relative to other processes. Process 702, on the other hand, shows a status of SN, indicating a sleeping process with decreased priority relative to other processes. Only the root user can adjust process priority downward (increased priority). Normal users can adjust the priorities of their own processes upward (decreased priority) if they choose. Killing Running ProcessesSometimes you need to forcefully kill a running processfor example, if a buggy piece of software has stopped responding, or if a single process has for some reason "run away" and is using vast amounts of CPU time, thus robbing the system of productivity potential. To kill a running process, use the kill command followed by the process ID number of the process you want to kill. For example, to kill process 702, enter the following: [root@workstation20 you]# kill 702 [root@workstation20 you]# This command sends a signal to process 702 that termination has been requested. Process 702 closes any open files and attempts to exit gracefully. From time to time, you find that even after trying to kill a process, it remains in the process list. Processes that can't be removed with a normal kill must then be terminated with the -KILL argument: [root@workstation20 you]# kill -KILL 702 [root@workstation20 you]# Because the -KILL argument is fairly destructiveit doesn't give a process any chance to close open files or network connections, but rather closes them forcefully as isyou should use it only when other termination attempts fail.
As you expect, the root user is able to terminate or kill any process in the system by process ID, and normal users are able to terminate or kill only processes that they own. |