Achild process (CP) in computing is aprocess created by another process (theparent process). This technique pertains tomultitasking operating systems, and is sometimes called asubprocess or traditionally asubtask.

There are two major procedures for creating a child process: thefork system call (preferred inUnix-like systems and thePOSIX standard) and thespawn (preferred in themodern (NT) kernel ofMicrosoft Windows, as well as in some historical operating systems).

Child processes date to the late 1960s, with an early form in later revisions of theMultiprogramming with a Fixed number of Tasks Version II (MFT-II) form of the IBMOS/360 operating system, which introducedsub-tasking (seetask). The current form in Unix draws onMultics (1969)^{[dubious –discuss]}, while the Windows NT form draws onOpenVMS (1978), fromRSX-11 (1972).

A child process inherits most of itsattributes, such asfile descriptors, from its parent. InUnix, a child process is typically created as a copy of the parent, using thefork system call. The child process can then overlay itself with a different program (usingexec) as required.^[1]

Each process may create many child processes but will have at most one parent process; if a process does not have a parent this usually indicates that it was created directly by thekernel. In some systems, includingLinux-based systems, the very first process (calledinit) is started by the kernel atbooting time and never terminates (seeLinux startup process); other parentless processes may be launched to carry out variousdaemon tasks inuserspace. Another way for a process to end up without a parent is if its parent dies, leaving anorphan process; but in this case it will shortly be adopted byinit.

The SIGCHLDsignal is sent to the parent of a child process when itexits, is interrupted, or resumes after being interrupted. By default the signal is simply ignored.^[2]

This sectionneeds expansion. You can help byadding missing information.(February 2014)

When a child process terminates, some information is returned to the parent process.

When a child process terminates before the parent has calledwait, the kernel retains some information about the process, such as itsexit status, to enable its parent to callwait later.^[3] Because the child is still consuming system resources but not executing it is known as azombie process. Thewait system call is commonly invoked in the SIGCHLD handler.

POSIX.1-2001 allows a parent process to elect for the kernel to automatically reap child processes that terminate by explicitly setting the disposition of SIGCHLD to SIG_IGN (although ignore is the default, automatic reaping only occurs if the disposition is set to ignore explicitly^[4]), or by setting the SA_NOCLDWAIT flag for the SIGCHLD signal. Linux 2.6 kernels adhere to this behavior, and FreeBSD supports both of these methods since version 5.0.^[5] However, because of historical differences betweenSystem V andBSD behaviors with regard to ignoring SIGCHLD, callingwait remains the most portable paradigm for cleaning up after forked child processes.^[6]

• exit
• pstree, for UNIX to find the child process (pstree PID, where PID is the process id of the process).

• pstree(1): print process trees – Linux User CommandsManual

• Process (computing)

• Webarchive template wayback links
• Articles with short description
• Short description is different from Wikidata
• All accuracy disputes
• Articles with disputed statements from February 2026
• Articles to be expanded from February 2014
• All articles to be expanded