When a child process is fork()ed, a parent may wait for the successful completion of the child via the wait() service (or one of its variants) so that the return result of that application can be read from the process descriptor block.
If the parent does not perform a wait() operation on the child process after it terminates, Unix will keep the process descriptor block active for this application in hopes that eventually the parent will wait() or that the parent will itself terminate.
If you perform the ps command in this scenario, you may find a number of "zombie" processes - these are processes marked with a Z in the output of ps that are children of a currently running parent that hasn't yet waited upon their completion. Normally, this isn't much of a problem, as eventually, the parent will terminate and cause the zombie tasks to be deallocated.
However, in a server application such as the email database server above, this becomes a problem, as the server generally never terminates, and as a result, the system list of process descriptor blocks becomes cluttered by zombies (processes that have properly terminated by haven't been waited upon by the parent).
To avoid this problem, Unix ensures that a terminating child application can send a signal to the parent indicating that it has terminated (SIG_CHILD). The parent should catch this signal, and issue a wait() or one of its variants to clean up the zombied process descriptor block.
For this question, describe the concept of a signal, and indicate how the parent application can be configured to act upon the SIG_CHILD signal from each child as they terminate to avoid the zombie issue.
In your answer, discuss the OS services that Unix provides to support signal processing.