UNIX baby Command

BABY(1)               USER COMMANDS               BABY(1)

NAME

baby - create new process from two parents

SYNOPSIS

baby -sex m|f [ -name name ]

DESCRIPTION

Baby is initiated when one parent process polls another server process
through a socket connection in the BSD version or through pipes in the
System V implementation.  Baby runs at a low priority for approximately
forty weeks and then terminates with a heavy system load.  Most systems
require constant monitoring when baby reaches its final stages of
execution.

Older implementations of baby did not require both initiating processes
to be present at the time of completion.  In those versions, the initiating
process which was not present was awakened and notified of the results
upon completion.  It has since been determined that the presence of
both parent processes results in generally lower system loads at the
completion, and thus current versions of baby expect both parent
processes to be active during the final stages.

Successful completion of baby(1) results in the creation and naming of
a new process.  Parent processes then broadcast messages to all other
processes, local and remote, informing them of their new status.

OPTIONS

-sex............define the gender of the created process
-name.........assign the name name to the new process

EXAMPLES

% baby -sex f -name Jacqueline
% completed successfully on July 9, 1992 at 9:11PM
% vital statistics: 8 pounds 3oz, 20 inches, dark hair
% The parent process, Kim Dunbar, is reportedly doing fine

SEE ALSO

cigar(6),dump(5),cry(3)

BUGS

Despite its complexity, baby only knows one signal, SIGCHLD, (or SIGCLD
in the System V implementation), which it uses to contact the parent
processes.  One or both parent processes must then inspect the baby
process to determine the signal's cause.

The sleep command may not work as expected on either parent process
for some time afterward, as each new instance of baby sends intermittent
signals to the parent processes which must be handled by the parents
immediately.

A baby process will frequently dump core, requiring either or both parent
processes to clean up after it.

Despite the reams of available documentation on invoking and maintaining
baby, most parent processes are overwhelmed.

Mr. Dunbar distributed the man pages for baby(1) this morning. I wish to confirm some known bugs, give possible solutions, and to warn him of several undocumented bugs.

We have also experienced the following undesirable behavior (as documented in the man pages) following the use of the baby(1) command using the syntax shown below:

baby -sex f -name Beth (in 1989)

baby -sex m -name Daniel (in 1991)

For the first 1.552e+07 seconds after the child process was started, neither parent process was able to execute the sleep command when the argument exceeded 600. While this bug was noted in the baby man page, the man page clearly states that the child process will only send SIGCHLD signals. Experience demonstrated that the child process sent SIGURG signals as well as SIGCHLD signals, even though the conditions requiring urgent processing did not exist with the child process.

Extensive research indicated that most signals were generally related to an I/O problem with the child process. In almost all cases, the signals indicated the child process either required input, or the output bin was full. In the case of the output bin full, the condition can be easily detected with the diapercheck(1) command using the -smell qualifier.

However, in some cases, the child process continued to send the SIGURG signals for unknown reasons after the I/O problem was rectified. In these cases the kill(1) command was considered as a possible alternative, but was considered unacceptable by the system administrator.

Additionally, we found that the first child process (-name Beth) began executing whine(2) continuously for no apparent reason beginning 1.5 years after the process startup. This condition appears to be ongoing even though the process has been running for 3.5 years. Unfortunately, it appears that this bug is getting steadily worse. The condition surrounding the bug is still being investigated, and no solution has been discovered to date.