This chapter is from the book
This chapter is from the book
This chapter is from the book
Working with Processes
Course Objectives Covered
-
Common Command Line Tasks (3036)
-
View Processes from the GUI and the Command Line Interface (3036)
-
Multiuser Processes and Multitasking in the Linux System (3036)
-
Monitor Processes (3038)
In this section, you'll learn about utilities used to manage a process and see how processes are utilized for all transactions. In the previous sections, many utilities and commands were discussed—each time one of them is issued, a process is started to carry out the request, as you will see in greater detail.
What Is a Process
Crucial to understanding this section is knowing that a process is any instance, command, or utility in execution. When you issue the command ls, as was discussed earlier, a process is started to run the utility and return the results.
Even the shell with which you are interacting is running as a process. When you give a command to be carried out, the shell will look to see if it can do so without any outside help. (Assume the command was really just an empty line: No other utilities are needed to return another prompt.) If your shell cannot perform the command, it will call another process to perform the action. The other process called is a child to your shell, which has become a parent to the new process.
When the child has completed performing its task, it returns its results to the parent, and then goes away. Because Linux is a multitasking operating system, there can be more than one child for any given parent. If the child cannot perform all of the tasks on its own (think of compiling an annual report), the child may need to call one or more additional processes. When it does this, it becomes the parent to those child processes.
NOTE
Barring any restrictions coded into it, every process has the ability to be a parent or child.
On a system, at any given time, there will be processes that you are running, there may be processes that others are running, and there will be processes that the system itself is running. The latter are often daemons—services that are running without interaction to provide functionality to the operating system. Examples of services daemons can perform include printing, running scheduled jobs, sending mail, monitoring run state, and so forth.
Working with ps
The ps command is key to any interaction with processes and is used to show process status. When run by itself (no options), ps will show the processes that you currently have running, with the last line always being itself (it is a running process as well). For example
$ ps PID TTY TIME CMD 19605 pts/0 00:00:34 bash 30089 pts/0 00:00:00 vi 30425 pts/0 00:00:00 paste 32040 pts/0 00:00:00 cat 1183 pts/0 00:00:00 awk 30679 pts/0 00:00:00 ps $
The first column is the process ID number—this is a unique number assigned to every process that executes. When the system is booted, the numbers begin incrementing until they reach a defined limit, then begin again through the numbering, using only the numbers that are free.
The second column indicates the terminal with which the user responsible for the process is associated. Because the list is only of processes for the user issuing the command, all terminal listings should be the same.
The third column indicates the amount of processor time that the process is utilizing. In most cases, processes can run quickly, sit idle, and so on, and utilize very little time. A very high time reading can indicate a process that is dragging down the performance of the system.
The fourth column is the name of the process (command) itself. In the first line, there is the user's shell—which must be there, or there would not be a user here at all: The user's shell is known as the session leader. The last line is the command that just executed. Those entries in between are other processes that the user is running.
The ps utility has a number of options to make it more flexible. The -a option removes obvious choices. For example, you know that you have to have a shell running or you would not be interacting with the system, so it isn't really as important to see that as others. Using the -a option, the display changes just slightly:
$ ps -a PID TTY TIME CMD 30089 pts/0 00:00:00 vi 30425 pts/0 00:00:00 paste 32040 pts/0 00:00:00 cat 1183 pts/0 00:00:00 awk 30685 pts/0 00:00:00 ps $
NOTE
ps -a will show all processes associated with the current tty except the session leader. Also note that the PID associated with ps increments with every running, as each requires a new process. It does not increment by one, in this case, for several other processes ran (probably in the background) between the first and second running of ps.
Using either the -A or the -e option (all or everything), it is possible to see every process running and not just those linked to the current tty:
$ ps -e
PID TTY TIME CMD
1 ? 00:00:04 init
2 ? 00:00:00 migration/0
3 ? 00:00:00 ksoftirqd/0
4 ? 00:00:00 migration/1
5 ? 00:00:00 ksoftirqd/1
6 ? 00:00:00 events/0
7 ? 00:00:00 events/1
8 ? 00:00:00 kacpid
9 ? 00:00:00 kblockd/0
10 ? 00:00:00 kblockd/1
11 ? 00:00:00 kirqd
14 ? 00:00:00 khelper
15 ? 00:00:00 pdflush
16 ? 00:00:07 pdflush
18 ? 00:00:00 aio/0
17 ? 00:00:00 kswapd0
19 ? 00:00:00 aio/1
175 ? 00:00:00 kseriod
437 ? 00:00:00 scsi_eh_0
439 ? 00:00:00 scsi_eh_1
479 ? 00:00:00 reiserfs/0
480 ? 00:00:00 reiserfs/1
659 ? 00:00:00 kcopyd
1463 ? 00:00:00 khubd
1739 ? 00:00:02 dhcpcd
1924 ? 00:00:00 syslogd
1930 ? 00:00:00 klogd
1979 ? 00:00:00 portmap
1980 ? 00:00:10 resmgrd
2042 ? 00:00:00 slpd
2152 ? 00:00:01 cupsd
2305 ? 00:00:33 powersaved
2402 ? 00:00:00 sshd
2495 ? 00:00:00 hwscand
2531 ? 00:00:00 slapd
3023 ? 00:00:00 master
3159 ? 00:00:00 cron
3164 ? 00:00:07 nscd
3334 ? 00:00:00 kdm
3385 tty1 00:00:00 mingetty
3386 tty2 00:00:00 mingetty
3387 tty3 00:00:00 mingetty
3388 tty4 00:00:00 mingetty
3389 tty5 00:00:00 mingetty
3390 tty6 00:00:00 mingetty
3531 ? 00:00:00 gpg-agent
7235 ? 00:00:00 qmgr
6751 ? 00:00:00 gpg-agent
6898 ? 00:00:22 X
6899 ? 00:00:00 kdm
6930 ? 00:00:00 kde
6965 ? 00:00:00 gpg-agent
6989 ? 00:00:00 kdeinit
6992 ? 00:00:00 kdeinit
6994 ? 00:00:00 kdeinit
6997 ? 00:00:00 kdeinit
7005 ? 00:00:00 artsd
7015 ? 00:00:00 kdeinit
7016 ? 00:00:00 kwrapper
7018 ? 00:00:00 kdeinit
7019 ? 00:00:03 kdeinit
7021 ? 00:00:00 kdeinit
7023 ? 00:00:00 kdeinit
7025 ? 00:00:02 kdeinit
7027 ? 00:00:03 kdeinit
7032 ? 00:00:00 kdeinit
7036 ? 00:00:00 kpowersave
7037 ? 00:00:01 suseplugger
7039 ? 00:00:00 susewatcher
7043 ? 00:00:00 kdeinit
7049 ? 00:00:00 krandrtray
7053 ? 00:00:01 kdeinit
7054 pts/1 00:00:00 bash
7116 ? 00:00:00 kdeinit
8886 ? 00:00:04 kdeinit
13641 ? 00:00:00 pickup
13737 pts/1 00:00:00 ps
$
There are several things to notice in the display shown. In no particular order, they are as follows:
-
Processes started when the system came up have the lowest number PIDs (notice items 1 through 19). As a general rule, these are mission-critical processes, and if they were not there, some or all of the system would be unusable.
-
Not all processes are tied to a terminal. If a question mark (?) is present, it indicates that the process is running on the system without terminal interaction and/or without a terminal being default standard output.
-
For every terminal without a user, there is a getty, or mingetty, running. This process sits and waits for a user to attempt to log on. Even though no user is using tty1 through tty6, it is easy to see that six other terminals can be used.
Other options that can be used to determine what information to display are
-
l to display a long listing (think of ls -l)
-
u to show username and related stats
-
f to show a full listing (everything possible)
The latter is often used, and favored by administrators, for the additional columns it adds to the display:
$ ps -f UID PID PPID C STIME TTY TIME CMD root 7054 7053 0 Oct12 pts/1 00:00:00 /bin/bash root 13745 7054 0 09:45 pts/1 00:00:00 ps -f $
There are four new columns that were not there before. The first column identifies the user ID associated with the process. The third column is the Parent Process ID—showing which process this one reports back to. The fourth column identifies whether scheduling is involved, and the fifth column is the time at which the process started.
NOTE
Notice that when using f, the CMD now lists the entire command and not just the first portion, as was done with the other displays.
These options can be combined with one another, and the most common combination is ef, which displays all processes in a full format:
$ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Sep28 ? 00:00:04 init [5] root 2 1 0 Sep28 ? 00:00:00 [migration/0] root 3 1 0 Sep28 ? 00:00:00 [ksoftirqd/0] root 4 1 0 Sep28 ? 00:00:00 [migration/1] root 5 1 0 Sep28 ? 00:00:00 [ksoftirqd/1] root 6 1 0 Sep28 ? 00:00:00 [events/0] root 7 1 0 Sep28 ? 00:00:00 [events/1] root 8 6 0 Sep28 ? 00:00:00 [kacpid] root 9 6 0 Sep28 ? 00:00:00 [kblockd/0] root 10 6 0 Sep28 ? 00:00:00 [kblockd/1] root 11 1 0 Sep28 ? 00:00:00 [kirqd] root 14 6 0 Sep28 ? 00:00:00 [khelper] root 15 7 0 Sep28 ? 00:00:00 [pdflush] root 16 6 0 Sep28 ? 00:00:07 [pdflush] root 18 7 0 Sep28 ? 00:00:00 [aio/0] root 17 1 0 Sep28 ? 00:00:00 [kswapd0] root 19 6 0 Sep28 ? 00:00:00 [aio/1] root 175 1 0 Sep28 ? 00:00:00 [kseriod] root 437 1 0 Sep28 ? 00:00:00 [scsi_eh_0] root 439 1 0 Sep28 ? 00:00:00 [scsi_eh_1] root 479 6 0 Sep28 ? 00:00:00 [reiserfs/0] root 480 7 0 Sep28 ? 00:00:00 [reiserfs/1] root 659 6 0 Sep28 ? 00:00:00 [kcopyd] root 1463 1 0 Sep28 ? 00:00:00 [khubd] root 1930 1 0 Sep28 ? 00:00:00 /sbin/klogd-c 1 -2 -x bin 1979 1 0 Sep28 ? 00:00:00 /sbin/portmap root 1980 1 0 Sep28 ? 00:00:10 /sbin/resmgrd daemon 2042 1 0 Sep28 ? 00:00:00 /usr/sbin/slpd lp 2152 1 0 Sep28 ? 00:00:01
Working with pstree and top
Two commands that are closely related to ps offer slightly different views of the processes. The first of these is pstree, which will graphically depict the relationship between the processes as shown in Figure 3.1.
)
Figure 3.1 The pstree utility
graphically shows the relationship between processes.
This graphically depicts the children beneath the main processes, and shows where each process fits in—what process is the parent of it, and so on.
The second utility related to ps is top. Not only does it show the current processes, but it stays active and continually updates the display. Additionally, the top of the screen depicts information about how many days the system has been up, the number of users, memory and swap statistics, and so on.
When top is running, you can press any of the following keys to interact with it:
-
h—Help
-
q—Quit
-
s—Set the delay between updates (default is five seconds)
-
spacebar—Update now rather than waiting for renewal interval
-
u—Display a single user only
The columns show the standard PID/CMD information, as well as the amount of memory and the number of CPU processes being utilized.
Ending a Process
Processes can be started in a plethora of ways. They are started automatically by the system as daemons, and started by the user in attempting to get a job done. Some processes start other processes, and the list goes on.
Under normal circumstances, a child process acts on behalf of, and reports to, a parent. When the child is no longer needed, it goes away on its own accord. There are situations, however, where processes become runaways—they are no longer needed, yet they continue to run and consume processes.
A parent process cannot (or should not) cease as long as there are child processes associated with it. Given that, a child process that fails to cease could keep a number of unneeded processes on a system. To illustrate, assume that a user's shell calls another process (A), which cannot do everything needed, and thus it calls another (B), and it in turn starts another (C).
Under normal conditions, when Process C finishes, it will report back to Process B and go away. Process B will massage the data, report back to Process A, and go away. Process A will do whatever it needs to with the data, and then return it to the user's shell and go away.
For a non-normal condition, assume that Process C has a glitch and does not end after reporting back to Process B. It continues to run: This prevents Process B from ending because it still has a child associated with it. We can assume that Process B returns its values to Process A, and it then returns its values to the user's shell. Process A, like Process B, cannot end because it still has a child associated with it. Because there is a glitch in Process C, three processes that are no longer needed continue to run.
Yet another possibility for the glitch (and it would depend on how applications are written) is that Process B could go ahead and end without Process C going away. Process A could do its task, and go away as well. What happens in this instance is that only Process C remains a problem, but now it has nonexistent parents above it, and has no idea who it reports to—it becomes a true runaway.
To solve problems with erratic processes, there is the kill command. This utility works with the following syntax:
kill {option} PID
Thus to get rid of the cat process, the sequence would be
$ ps -f UID PID PPID C STIME TTY TIME CMD root 19605 19603 0 Aug10 pts/0 00:00:34 bash root 30089 19605 0 Aug20 pts/0 00:00:00 vi fileone root 30425 19605 0 Aug20 pts/0 00:00:00 paste -d
This "politely" asks the process to terminate. It is polite because there are 32 different ways to kill a process (signals to send), and this is the safest method of doing so. In a great many instances, the process will simply ignore the request and continue on. When that happens, you can use one of the other 32 ways by specifying the number to use. Among the possibilities are
-
-1 On hangup/disconnect
-
-2 Using an interrupt (Ctrl+C) sequence
-
-3 Upon quit
-
-9 Without regard—immediately
-
-15 (the default)
NOTE
To see a list of signals on your system, use the command kill -l. The first 32 signals are standard, but many times a list of up to 64 is shown. Those signals between 33 and 64 are not standard and are intended for real-time application use.
To illustrate, assume the cat process will not go away politely; the sequence of operations then becomes
$ ps -f UID PID PPID C STIME TTY TIME CMD root 19605 19603 0 Aug10 pts/0 00:00:34 bash root 30089 19605 0 Aug20 pts/0 00:00:00 vi fileone root 30425 19605 0 Aug20 pts/0 00:00:00 paste -d
It is highly recommended that signal 15 (terminate) always be attempted before signal 9 (kill) is used. It is also highly recommended that you make certain there are no child processes beneath a process before killing it. If child processes exist, they should be removed first before proceeding further.
Just when you thought it couldn't get any more bloody, another command—killall—can be used to get rid of a process by name, versus PID. killall also has the ability (with the -w option) to wait for processes to die, and to require confirmation (with the -i option) before killing.
Background and Foreground
When a process is started, the default is for it to run in the foreground. In the foreground, it becomes the only job the user can work on and interaction is based upon completion of the job. For example, when a user runs ls -l, the display appears on his or her terminal, and he or she is unable to issue another command until ls has finished.
To run a process in the background, simply add an ampersand (&) to the end—this allows you to run more than one command at the same time. For example, the sleep command simply allows the process to wait a given number of seconds before anything else happens and it can be used by itself as a means of illustration:
$ sleep 90 & [5] 31168 $
The number that appears in the brackets is equal to the number of jobs you currently have running in the background. The number following it (31168 in this case) is the process ID (PID) number of this job.
NOTE
The PID of the last job placed in the background can also be referenced as $!.
Placing the job in the background allows the user to continue working and starting other processes. If you must wait for a process to finish before starting another, the wait command, used with the PID of the process, can cease processing until the specified process finishes. For example
$ sleep 120 & [5] 31175 $ $ wait 31175
The prompt does not return as long as 31175 remains a valid PID.
jobs
To see the jobs that you have running in the background, use the command jobs:
$ jobs [1] Stopped vi fileone (wd: ~) [2]- Stopped paste -d' fileone filetwo ' (wd: ~) [4]+ Stopped awk -F: questions (wd: ~) [5] Done sleep 120 $
Jobs that were terminated (#3) do not appear, and jobs that have finished (#5) will only show up one time (the next time jobs is run, #5 will not appear). If the job is the most recent job that can run, or is running, a plus sign (+) will follow the job number brackets. The next most recent job is indicated by a minus sign (-). The wd information references the working directory.
The -l option will add the PID numbers to the display, and the -p option can be used to show only the PID numbers of the processes. The -n option can be used to show only jobs that have been suspended.
fg
A job that is running in the background can be moved to the foreground through the use of the fg command. The syntax for fg allows reference to a job using a percent sign (%) and the job number. For example, the following sequence starts a two-minute sleep sequence in the background, and then moves it into the foreground:
$ sleep 120 & [5] 31206 $ $ fg %5 sleep 120
Notice that the command being executed is echoed to the screen as it is brought to the foreground. Where %5 was used, you can also reference the two most recent jobs by %+ and %-, respectively. If you don't know the job number (and can't remember to use the jobs command), you can refer to a job by a portion of its name when using it after the percent sign and question mark (%?). For example
$ fg %?v vi fileone
bg
The opposite of the foreground (fg) command is the background (bg) command. This allows you to take a job running in the foreground and move it to the background. Before you can do so, however, you must suspend the job (in order to get the prompt back).
Suspending a job is accomplished by pressing the keyboard sequence equal to the susp signal—Ctrl+Z, by default. When suspended, the job will stop and not start again until moved into the foreground or background. For example
$ sleep 180
{Ctrl+Z pressed}
[5]+ Stopped sleep 180
$
Issuing the bg command will now move the job into the background and change the status to Running.