Home > Articles

  • Print
  • + Share This
This chapter is from the book

Working with Processes

Course Objectives Covered

  1. Common Command Line Tasks (3036)

  1. View Processes from the GUI and the Command Line Interface (3036)

  2. Multiuser Processes and Multitasking in the Linux System (3036)

  3. 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
  /usr/sbin/cupsd
root   2495    1 0 Sep28 ?    00:00:00 [hwscand]
root   3023    1 0 Sep28 ?    00:00:00
  /usr/lib/postfix/master
root   3159    1 0 Sep28 ?    00:00:00
  /usr/sbin/cron
root   3164    1 0 Sep28 ?    00:00:07
  /usr/sbin/nscd
root   3334    1 0 Sep28 ?    00:00:00
  /opt/kde3/bin/kdm
root   3385    1 0 Sep28 tty1   00:00:00 /sbin/mingetty
  --noclear tty1
root   3386    1 0 Sep28 tty2   00:00:00 /sbin/mingetty
  tty2
root   3387    1 0 Sep28 tty3   00:00:00 /sbin/mingetty
  tty3
root   3388    1 0 Sep28 tty4   00:00:00 /sbin/mingetty
  tty4
root   3389    1 0 Sep28 tty5   00:00:00 /sbin/mingetty
  tty5
root   3390    1 0 Sep28 tty6   00:00:00 /sbin/mingetty
  tty6
postfix 7235 3023 0 Sep28 ?    00:00:00 qmgr -l -t
  fifo -u
root   6899  3334 0 Oct12 ?    00:00:00 -:0       
root   6930  6899 0 Oct12 ?    00:00:00 /bin/sh
  /usr/X11R6/bin/kde
root   6989     1 0 Oct12 ?    00:00:00 kdeinit:
  Running...   
root   6992     1 0 Oct12 ?    00:00:00 kdeinit:
  dcopserver --nosid
root   6994  6989 0 Oct12 ?    00:00:00 kdeinit:
  klauncher    
root   6997     1 0 Oct12 ?    00:00:01 kdeinit: kded      
root   7015     1 0 Oct12 ?    00:00:00 kdeinit:
  knotify     
root   7016  6930 0 Oct12 ?    00:00:00 kwrapper
  ksmserver
root   7018     1 0 Oct12 ?    00:00:00 kdeinit:
  ksmserver    
root   7019  6989 0 Oct12 ?    00:00:03 kdeinit: kwin
  -session 117f000002000109640216500000063920000_1097649388_
  170101
root   7021     1 0 Oct12 ?    00:00:00 kdeinit:
  kwrited     
root   7023     1 0 Oct12 ?    00:00:00 kdeinit:
  khotkeys    
root   7025     1 0 Oct12 ?    00:00:02 kdeinit:
  kdesktop    
root   7027     1 0 Oct12 ?    00:00:03 kdeinit:
  kicker     
root   7032     1 0 Oct12 ?    00:00:00 kdeinit:
  klipper     
root   7036     1 0 Oct12 ?    00:00:00 kpowersave
root   7043     1 0 Oct12 ?    00:00:00 kdeinit:
  kio_uiserver  
root   7049     1 0 Oct12 ?    00:00:00 krandrtray -
  session 117f000002000109640362700000063920018_1097649388_
  152381
root   7053  6989 0 Oct12 ?    00:00:01 kdeinit:
  konsole     
root   7054  7053 0 Oct12 pts/1 00:00:00 /bin/bash
root   8886  6989 0 Oct13 ?    00:00:05 kdeinit:
  konqueror --silent
postfix 13641 3023 0 08:24 ?    00:00:00 pickup -l -t
  fifo -u
root   13747  7054 0 09:45 pts/1  00:00:00 ps -ef
$

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.1Figure 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
  fileone filetwo?
root   32040 19605 0 Aug22 pts/0  00:00:00 cat
root   1183  19605 0 Aug23 pts/0  00:00:00 awk -F:
  questions
root   30900 19605 0 14:25 pts/0  00:00:00 ps -f
$
$ kill 32040
$ 

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
  fileone filetwo?
root   32040 19605 0 Aug22 pts/0  00:00:00 cat
root    1183 19605 0 Aug23 pts/0  00:00:00 awk -F:
  questions
root   30996 19605 0 14:25 pts/0  00:00:00 ps -f
$
$ kill 32040
$ 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
  fileone filetwo?
root   32040 19605 0 Aug22 pts/0  00:00:00 cat
root    1183 19605 0 Aug23 pts/0  00:00:00 awk -F:
  questions
root   30998 19605 0 14:25 pts/0  00:00:00 ps -f
$
$ kill -9 32040
[3]- Killed
$ 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
  fileone filetwo?
root   1183 19605 0 Aug23 pts/0  00:00:00 awk -F:
  questions
root   31000 19605 0 14:25 pts/0  00:00:00 ps -f
$

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.

  • + Share This
  • 🔖 Save To Your Account