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.