The Linux Programming Interface

726 Chapter 34

Suppose that we include this code in a program executed from the shell. Figure 34-3

shows the state of processes before and after the parent exits.

After the parent terminates, the child process in Figure 34-3 is not only an

orphaned process, it is also part of an orphaned process group. SUSv3 defines a pro-

cess group as orphaned if “the parent of every member is either itself a member of

the group or is not a member of the group’s session.” Put another way, a process

group is not orphaned if at least one of its members has a parent in the same ses-

sion but in a different process group. In Figure 34-3, the process group containing

the child is orphaned because the child is in a process group on its own and its par-

ent (init) is in a different session.

By definition, a session leader is in an orphaned process group. This follows

because setsid() creates a new process group in the new session, and the parent

of the session leader is in a different session.

Figure 34-3: Steps in the creation of an orphaned process group

To see why orphaned process groups are important, we need to view things from the

perspective of shell job control. Consider the following scenario based on Figure 34-3:

1. Before the parent process exits, the child was stopped (perhaps because the
   parent sent it a stop signal).


2. When the parent process exits, the shell removes the parent’s process group
   from its list of jobs. The child is adopted by init and becomes a background
   process for the terminal. The process group containing the child is orphaned.


3. At this point, there is no process that monitors the state of the stopped child
   via wait().

Login shell

(session

leader)

exec()fork(),

Login shell

(session

leader)

Child

init adopts

a) Creation of parent

and child processes

b) Adoption of child by init after

parent exits

Process

Key

Process group

Session

Orphaned

process group

fork()

Parent

(process

group leader)

Child