Parent process
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
In computing, a parent process is a process that has created one or more child processes.
Unix-like systems
In
The
Linux
In the
Zombie processes
The operating system maintains a table that associates every process, by means of its process identifier (generally referred to as "pid") to the data necessary for its functioning. During a process's lifetime, such data might include memory segments designated to the process, the arguments it's been invoked with, environment variables, counters about resource usage, user-id, group-id and group set, and maybe other types of information.
When a process terminates its execution, either by calling
By default, the system assumes that the parent process is indeed interested in such information at the time of the child's termination, and thus sends the parent the signal
Such a terminated process whose data has not been collected is called a zombie process, or simply a zombie, in the UNIX parlance. The name is a humorous analogy due to considering terminated process as "no longer alive" or "dead"—since it has really ceased functioning—and a lingering dead process still "incarnated" in the "world of the living" processes—the process table—which is therefore actually "undead", or "zombie".
Zombie processes might pose problems on systems with limited resources or that have limited-size process tables, as the creation of new, active processes might be prevented by the lack of resources still used by long lasting zombies.
It is, therefore, a good programming practice in any program that might spawn child processes to have code to prevent the formation of long lasting zombies from its original children. The most obvious approach is to have code that calls wait or one of its relatives somewhere after having created a new process. If the program is expected to create many child processes that may execute asynchronously and terminate in an unpredictable order, it is generally good to create a
Orphan processes
Orphan processes are an opposite situation to zombie processes, referring to the case in which a parent process terminates before its child processes, which are said to become "orphaned". Unlike the asynchronous child-to-parent notification that happens when a child process terminates (via the SIGCHLD signal), child processes are not notified immediately when their parent finishes. Instead, the system simply redefines the "parent PID" field in the child process's data to be the process that is the "ancestor" of every other process in the system, whose PID generally has the value of 1 (one), and whose name is traditionally "init" (except in the Linux kernel 3.4 and above [more info below]). Thus, it was said that init "adopts" every orphan process on the system.[4][5]
A somewhat common assumption by programmers new to UNIX was that the child processes of a terminating process will be adopted by this process's immediate parent process (hence those child processes' "grandparent"). Such assumption was incorrect – unless, of course, that "grandparent" was the init itself.
After Linux kernel 3.4 this is no longer true, in fact processes can issue the prctl() system call with the PR_SET_CHILD_SUBREAPER option, and as a result they, not process #1, will become the parent of any of their orphaned descendant processes. This is the way of working of modern service managers and daemon supervision utilities including systemd, upstart, and the nosh service manager.
This is an abstract of the manual page, reporting that:
A subreaper fulfills the role of init(1) for its descendant processes. When a process becomes orphaned (i.e., its immediate parent terminates) then that process will be reparented to the nearest still living ancestor subreaper. Subsequently, calls to getppid() in the orphaned process will now return the PID of the subreaper process, and when the orphan terminates, it is the subreaper process that will receive a SIGCHLD signal and will be able to wait(2) on the process to discover its termination status.[6]
References
- ISBN 978-0136006633.
- ^ Srinivasan, Sundar (2010-09-01). "An Engineer's Options & Futures: A Sneak-Peek into Linux Kernel - Chapter 2: Process Creation". Sunnyeves.blogspot.com. Retrieved 2014-04-30.
- ^ "wait man page - System Calls". www.mankier.com.
- ^ "init comes first".
- ^ "An overview of Linux processes". IBM. 26 March 2012.
- ^ "Linux Programmer's Manual".