Processes come from processes. This basic Unix concept begs a philosophical question. The answer is "the first process is created spontaneously by the kernel during system initialization". That first process is used to hold the ancestor of all later processes: init. init(8) will be covered in the module on Startup and Shutdown. 

Once a process exists, it can create a child process using a facility called fork and exec.

Though most often used in concert, fork and exec are actually two separate system calls:

• fork() duplicates the current process
• exec() reads a new program file into an existing process

fork and exec create a parent-child relationship between the forking process (the parent) and the newly-created process (the child), which is later the subject of the exec. This relationship can be seen in the execution of the simple command:

The execution of this command proceeds as follows:

• Upon submission of the ls command, the shell executes a fork() call. This results in two identical shell processes. Although these are separate processes, the program executing in them is identical with one exception: the return value of the fork() call can be used to distinguish which process is the parent and which is the child.
• Since the child was started in the foreground, the parent executes a wait() system call, effectively putting itself to sleep until the child exits.
• The child process executes an exec() of the ls program. This reads the ls program from its program file on disk into the existing [child] process. At the time of the exec(), most of the content of the process is reset. Some types of information is copied from the parent to the child, however, to initialize it. The most important parts of this information are environment variables and open file descriptors. We know about environment variables. Since the open file descriptors are copied, rather than the files being re-opened, the parent and child essentially share the same file descriptors for open files.
  
• The ls program runs to completion. When it exits, it sends a signal to its parent indicating the child has terminated. The child cannot exit until the parent receives the signal. (i.e., the signal must trigger an event in the parent.) This requires the parent to be active.
• The parent shell awakens on receipt of the signal, and continues. This is what causes the prompt to reappear.

Before we continue, let's examine some ramifications of the above scenario:

• The fact that open file descriptors are copied across the exec() call means that if the parent has standard output open to a file, standard output will be opened to the same file for the child process, and the child will continue to write (append) to it. This is true for input files as well - if standard input is opened for the parent and the child just reads from it, the input will continue to be read by the child, then the parent will continue from where the child leaves off when the child exits.
• The child process appears for a moment, then exits. By the time the shell reawakens, the child is gone. This explains why an execution of the ps command 'sees' itself as a process, although it does not exist when we run another command. It also explains why the pid of the ps command changes each time we run it - because it is a different instance of ps.
• If the parent cannot receive the notification that the child is exiting (SIGCHLD signal), the child cannot exit. (see below)

Children that cannot exit

The inability of the parent to receive the SIGCHLD signal can be due to either 

• the parent exiting before the child. Children thus "orphaned" on a Unix system are supposed to be adopted by init(8). Historically, this was an imperfect handoff resulting in a few unadopted orphans.
• the parent being temporarily unable to respond. 

Both of these circumstances result in child that is unable to exit. Since this is equivalent to a 'living dead' state, the state is called Zombie (Z). A zombie is stripped of its resources and held in limbo waiting for the parent to respond. 

Zombies may exist for a short while on any running Unix system. The most common situation that gives rise to a zombie is that the parent is simply asleep. When it awakens, the zombie will be cleared. Although zombies do not tie up any resources (such as memory pages or compute time), they do clog up a slot in the process table and their accumulation will eventually degrade system performance. 

Background processes

If a process is run in the background, the sequence of events surrounding the fork() and exec() calls must be modified slightly. In this case, the parent does not go to sleep until the child exits: it continues to run in parallel. Other details are the same.

bash bends some of the standard rules of process handling to try to smooth the rough edges. It is often best to run a less 'friendly' shell if you want to experiment with how Unix itself works, such as the Korn shell, ksh, when investigating process and job control and signals.

Threads

Rather than using fork(), threads use one of the clone() system calls. These system calls set the child up to share certain types of data with the parent.