# Child process > Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Child_process > Markdown URL: https://mediated.wiki/source/Child_process.md > Source: https://en.wikipedia.org/wiki/Child_process > Source revision: 1350880493 > License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/) {{Short description|Computing process created by another process}} A '''child process''' (CP) in computing is a [process](/source/process_(computing)) created by another process (the [parent process](/source/parent_process)). This technique pertains to [multitasking operating systems](/source/computer_multitasking), and is sometimes called a '''subprocess''' or traditionally a '''subtask'''. There are two major procedures for creating a child process: the [fork system call](/source/fork_(system_call)) (preferred in [Unix-like](/source/Unix-like) systems and the [POSIX](/source/POSIX) standard) and the [spawn](/source/spawn_(computing)) (preferred in the [modern (NT) kernel](/source/ntoskrnl.exe) of [Microsoft Windows](/source/Microsoft_Windows), as well as in some historical operating systems). == History == Child processes date to the late 1960s, with an early form in later revisions of the [Multiprogramming with a Fixed number of Tasks](/source/Multiprogramming_with_a_Fixed_number_of_Tasks) Version II (MFT-II) form of the IBM [OS/360](/source/OS%2F360) operating system, which introduced ''sub-tasking'' (see [task](/source/Task_(computing))). The current form in Unix draws on [Multics](/source/Multics) (1969), {{Dubious|Unix based on Multics|date=February 2026}} while the Windows NT form draws on [OpenVMS](/source/OpenVMS) (1978), from [RSX-11](/source/RSX-11) (1972). ==Children created by fork== A child process inherits most of its [attribute](/source/Attribute_(computing))s, such as [file descriptor](/source/file_descriptor)s, from its parent. In [Unix](/source/Unix), a child process is typically created as a copy of the parent, using the [fork](/source/fork_(system_call)) system call. The child process can then overlay itself with a different program (using {{mono|[exec](/source/Exec_(system_call))}}) as required.{{FOLDOC|Child+process}} 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 the [kernel](/source/kernel_(operating_system)). In some systems, including [Linux](/source/Linux_kernel)-based systems, the very first process (called [init](/source/init)) is started by the kernel at [booting](/source/booting) time and never terminates (see [Linux startup process](/source/Linux_startup_process)); other parentless processes may be launched to carry out various [daemon](/source/daemon_(computing)) tasks in [userspace](/source/userspace). Another way for a process to end up without a parent is if its parent dies, leaving an [orphan process](/source/orphan_process); but in this case it will shortly be adopted by ''init''. The SIGCHLD [signal](/source/Unix_signal) is sent to the parent of a child process when it [exit](/source/exit_(system_call))s, is interrupted, or resumes after being interrupted. By default the signal is simply ignored.{{man|bd|signal.h|SUS}} ==Children created by spawn== {{main|Spawn (computing)}} {{expand section|date=February 2014}} ==End of life== When a child process terminates, some information is returned to the parent process. When a child process terminates before the parent has called [wait](/source/wait_(system_call)), the kernel retains some information about the process, such as its [exit status](/source/exit_status), to enable its parent to call ''wait'' later.{{man|2|wait|Linux|wait for process to change state}} Because the child is still consuming system resources but not executing it is known as a [zombie process](/source/zombie_process). The ''wait'' system call is commonly invoked in the SIGCHLD handler. [POSIX.1-2001](/source/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{{cite web|url=http://www.win.tue.nl/~aeb/linux/lk/lk-5.html#ss5.5 |title=The Linux kernel: Signals |publisher=Win.tue.nl |date= |accessdate=2014-04-30}}), 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.[http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?signal+3] {{webarchive|url=https://web.archive.org/web/20110929182629/http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?signal+3|date=September 29, 2011}} However, because of historical differences between [System V](/source/System_V) and [BSD](/source/BSD) behaviors with regard to ignoring SIGCHLD, calling ''wait'' remains the most portable paradigm for cleaning up after forked child processes.{{man|2|sigaction|Linux|examine and change a signal action}} ==See also== * [exit](/source/Exit_(system_call)) * [pstree](/source/pstree), for UNIX to find the child process (''pstree PID'', where PID is the process id of the process). ==References== {{Reflist}} ==External links== * {{man|1|pstree|die.net|print process trees}} Category:Process (computing) --- Adapted from the Wikipedia article [Child process](https://en.wikipedia.org/wiki/Child_process) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Child_process?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.