This chapter introduces the concept of processes and how you use UNIX to interact with them.
When you execute a program on your UNIX system, the system creates a special environment for that program. This environment contains everything needed for the system to run the program as if no other program were running on the
Each process has process context, which is everything that is unique about the state of the program you are currently running. The process context includes then following:
Every time you execute a program the UNIX system does a fork, which performs a series of operations to create a process context and then execute your program in that context. The steps include the following:
After the fork is complete, UNIX runs your program. One of the differences between UNIX and many other operating systems is that UNIX performs this two-step procedure to run a program. The first step is to create a new process that's just like the
parent. The second is to execute a different program. This procedure allows interesting variations. (See the section "A Special Process Called Daemon.")
When you enter ls to look at the contents of your current working directory, UNIX does a series of things to create an environment for ls and the run it:
Because processes are so important to getting things done, UNIX has several commands that enable you to examine processes and modify their state. The most frequently used command is ps, which prints out the process status for processes running on your
system. Each system has a slightly different version of the ps command, but there are two main variants, the System V version and the Berkeley version, covered in this section. Different versions of ps do similar things, but have somewhat different output
and are controlled using different options. The X/Open Portability Guide makes an attempt to standardize somewhat on output of the ps command. The ps command is covered in more detail in chapter 19, "Administrative Processes."
On a System V or XPG-compliant system, you can examine all the processes you are running by entering ps -f and you will get output such as the following:
$ ps -f UID PID PPID C STIME TTY TIME COMMAND root 14931 136 0 08:37:48 ttys0 0:00 rlogind sartin 14932 14931 0 08:37:50 ttys0 0:00 -sh sartin 15339 14932 7 16:32:29 ttys0 0:00 ps -f $
Look at this example and you can see that root (the system administration user) is running rlogind as process 14931. This process is a special kind of administrative program, called a daemon (daemons are described in the section "A Special Process
Called Daemon"). This particular daemon is responsible for managing a connection from rlogin, which is described in Chapter 8, "Getting Around the Network." As you can see from the next line, there is a process called -sh, which is a Bourne
shell. The shell has rlogind as its parent because the daemon did a fork to run the login shell. Similarly, there is a ps -f command that has the shell as its parent.
Earlier in this chapter you learned that the shell creates a new process for each command you execute. This section covers in a bit more detail how the shell creates and manages processes.
When you type a command to your shell user interface, the shell performs a series of tasks to process the command. Although the steps may seem a bit cumbersome at first, they create an environment that is highly flexible.
The first thing the shell does is alias and built-in processing to see if your command is one of the shell's internally implemented functions. Each shell implements a number of functions internally either because external implementation would be
difficult (for example, while loops) or because internal implementation is a big performance win (for example, echo in some shells). One reason the built-in commands are easier is that they can operate directly in the shell process rather than forcing the
shell to create a new process to run a different command. That new command would not have access to the shell's memory.
If the command you typed is not a built-in command (for example, if you entered ps), the shell performs a fork to create a new process. Your UNIX system allocates the necessary resources. The shell modifies the process environment to configure correctly
for the command to be executed. This includes any input or output redirect you may have requested (including command pipelines) and creating a new background process group if you executed the command in the background.
Finally, the shell performs an exec to execute the program that you requested. The program will replace the shell with a forked shell, but your shell will still be running.
The following happens when you enter ps -f > t1 followed by cat t1:
$ ps -f > t1 $ cat t1 UID PID PPID C STIME TTY TIME COMMAND root 14931 136 0 08:37:48 ttys0 0:00 rlogind sartin 14932 14931 0 08:37:50 ttys0 0:00 -sh sartin 15339 14932 7 16:32:29 ttys0 0:00 ps -f $
UNIX performs the following steps to execute ps -f> t1:
You can tell your shell to execute commands in the background, which tells the shell not to wait for the command to complete. This enables you to run programs without having to wait for them to complete.
This example is almost the same as the previous example. The only difference is that the ps command is executed in the background. The following happens when you are using the Bourne shell and enter ps -f > t1 & followed by cat t1:
$ ps -f > t1 & 15445 $ cat t1 UID PID PPID C STIME TTY TIME COMMAND root 14931 136 1 08:37:48 ttys0 0:00 rlogind sartin 14932 14931 0 08:37:50 ttys0 0:00 -sh sartin 15445 14932 8 17:31:14 ttys0 0:00 ps -f $
UNIX performs the following steps to execute ps -f > t1 &:
One of the things the fork/exec model enables is creating command pipelines, a series of commands with the output of one command as the input for the next. This powerful notion is one of the major advantages of UNIX over some other systems. See Chapter
1, "Operating Systems."
Creating a pipeline is similar to creating an ordinary command. The difference is in how output is redirected. In the ordinary case, the shell performs some simple I/O redirection before executing the program. In the pipeline case, the shell will
instead connect the standard output of one command as the standard input of another.
If you enter ps -f | grep sartin you might get output such as the following:
$ ps -f | grep sartin sartin 14932 14931 1 08:37:50 ttys0 0:00 -sh sartin 15424 14932 1 17:15:02 ttys0 0:00 grep sartin sartin 15425 15424 7 17:15:02 ttys0 0:00 ps -f $
In order to get this output, the shell went through the following series of steps:
As you learned in Chapter 1, many of the features that are sometimes implemented as part of the kernel, the core of the operating system, are not in the UNIX kernel. Instead, many of these features are implemented using special processes called daemons.
A daemon is a process that detaches itself from the terminal and runs, disconnected, in the background, waiting for requests and responding to them. Many system functions are commonly performed by daemons, including the sendmail daemon, which handles mail,
and the NNTP daemon, which handles USENET news. Many other daemons may exist on your system; check the documentation for more information.
Generally only system administrators need to know about most daemons, but there are three daemons that are important and widespread enough that you should probably have a minimal understanding of what they do; they are init, inetd, and cron.
In a way the init program is the "super daemon." It takes over the basic running of the system when the kernel has finished the boot process. It is responsible for the following:
For further information on init, see Chapter 34, "Starting Up and Shutting Down."
A second powerful daemon is the inetd program common to many UNIX machines (including those based on BSD and many that are based on System V). The inetd process is the network "super server" daemon. It is responsible for starting network
services that do not have their own stand-alone daemons. For example, inetd usually takes care of incoming rlogin, telnet, and ftp connections. (See Chapter 9, "Getting Around the Network.")
For further information on inetd, see Chapter 37, "Networking."
Another common daemon is the cron program, which is responsible for running repetitive tasks on a regular schedule. It is a perfect tool for running system administration tasks such as backup and system logfile maintenance. It can also be useful for
ordinary users to schedule regular tasks including calendar reminders and report generation. For more information, see Chapter 20, "Scheduling Processes."
In this chapter you have learned what a UNIX process is, how your interaction with UNIX starts and stops processes, and a little bit about a few special processes called daemons. A process is an entire execution environment for your computer program; it is almost like having a separate computer that executes your program. UNIX switches quickly between processes to give the illusion that they are all running simultaneously. You start a process any time you run a command or pipeline in the shell. You can even start a process in the background and perform other tasks while it is executing. Several processes called daemons run on your system to perform special tasks and supply services that some operating systems supply in the kernel.