 | This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these messages)
|
In computing, a parent process is a process that has created one or more child processes.
| This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these messages)
|
In computing, a parent process is a process that has created one or more child processes.
In Unix-like operating systems, every process except process 0 (the swapper) is created when another process executes the fork() system call. The process that invoked fork is the parent process and the newly created process is the child process. Every process (except process 0) has one parent process, but can have many child processes.
The operating system kernel identifies each process by its process identifier. Process 0 is a special process that is created when the system boots; after forking a child process (process 1),process 0 becomes the swapper process (sometimes also known as the "idle task"). Process 1, known as init , is the ancestor of every other process in the system. [1]
In the Linux kernel, in which there is a very slim difference between processes and POSIX threads, there are two kinds of parent processes, namely real parent and parent. Parent is the process that receives the SIGCHLD signal on child's termination, whereas real parent is the thread that actually created this child process in a multithreaded environment. For a normal process, both these two values are same, but for a POSIX thread which acts as a process, these two values may be different. [2]
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 exit (even if implicitly, by executing a return command from the main function) or by receiving a signal that causes it to terminate abruptly, the operating system releases most of the resources and information related to that process, but still keeps the data about resource utilization and the termination status code, because a parent process might be interested in knowing if that child executed successfully (by using standard functions to decode the termination status code) and the amount of system resources it consumed during its execution.
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 SIGCHLD to alert that there is some data about a child to be collected. Such collection is done by calling a function of the wait family (either wait itself or one of its relatives, such as waitpid, waitid or wait4). As soon as this collection is made, the system releases those last bits of information about the child process and removes its pid from the process table. However, if the parent process lingers in collecting the child's data (or fails to do it at all), the system has no option but keep the child's pid and termination data in the process table indefinitely.
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 handler for the SIGCHLD signal, calling one of the wait-family function in a loop, until no uncollected child data remains. It is possible for the parent process to completely ignore the termination of its children and still not create zombies, but this requires the explicit definition of a handler for SIGCHLD through a call to sigaction with the special option flag SA_NOCLDWAIT. [3]
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]
On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table: it is a process in the "terminated state". This occurs for the child processes, where the entry is still needed to allow the parent process to read its child's exit status: once the exit status is read via the wait system call, the zombie's entry is removed from the process table and it is said to be "reaped". A child process initially becomes a zombie, only then being removed from the resource table. Under normal system operation, zombies are immediately waited on by their parent and then reaped by the system. Processes that stay zombies for a long time are usually an error and can cause a resource leak. Generally, the only kernel resource they occupy is the process table entry, their process ID. However, zombies can also hold buffers open, consuming memory. Zombies can hold handles to file descriptors, which prevents the space for those files from being available to the filesystem. This effect can be seen by a difference between du and df. While du may show a large amount of free disk space, df will show a full partition. If the zombies are not cleaned, this can fill the root partition and crash the system.
In computing, a process is the instance of a computer program that is being executed by one or many threads. There are many different process models, some of which are light weight, but almost all processes are rooted in an operating system (OS) process which comprises the program code, assigned system resources, physical and logical access permissions, and data structures to initiate, control and coordinate execution activity. Depending on the OS, a process may be made up of multiple threads of execution that execute instructions concurrently.
A kernel panic is a safety measure taken by an operating system's kernel upon detecting an internal fatal error in which either it is unable to safely recover or continuing to run the system would have a higher risk of major data loss. The term is largely specific to Unix and Unix-like systems. The equivalent on Microsoft Windows operating systems is a stop error, often called a "blue screen of death".
A background process is a computer process that runs behind the scenes and without user intervention. Typical tasks for these processes include logging, system monitoring, scheduling, and user notification.
In computing, particularly in the context of the Unix operating system and its workalikes, fork is an operation whereby a process creates a copy of itself. It is an interface which is required for compliance with the POSIX and Single UNIX Specification standards. It is usually implemented as a C standard library wrapper to the fork, clone, or other system calls of the kernel. Fork is the primary method of process creation on Unix-like operating systems.
A child process in computing is a process created by another process. This technique pertains to multitasking operating systems, and is sometimes called a subprocess or traditionally a subtask.
In Unix and Unix-like computer operating systems, a file descriptor is a process-unique identifier (handle) for a file or other input/output resource, such as a pipe or network socket.
An orphan process is a computer process whose parent process has finished or terminated, though it remains running itself.
Signals are standardized messages sent to a running program to trigger specific behavior, such as quitting or error handling. They are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems.
On POSIX-compliant platforms, SIGHUP is a signal sent to a process when its controlling terminal is closed. It was originally designed to notify the process of a serial line drop. SIGHUP is a symbolic constant defined in the header file signal.h.
In Unix-based computer operating systems, init is the first process started during booting of the operating system. Init is a daemon process that continues running until the system is shut down. It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel during the booting process; a kernel panic will occur if the kernel is unable to start it, or it should die for any reason. Init is typically assigned process identifier 1.
In computing, sigaction is a function API defined by POSIX to give the programmer access to what a program's behavior should be when receiving specific OS signals.
Fork–exec is a commonly used technique in Unix whereby an executing process spawns a new program.
In Unix and Unix-like operating systems, job control refers to control of jobs by a shell, especially interactively, where a "job" is a shell's representation for a process group. Basic job control features are the suspending, resuming, or terminating of all processes in the job/process group; more advanced features can be performed by sending signals to the job. Job control is of particular interest in Unix due to its multiprocessing, and should be distinguished from job control generally, which is frequently applied to sequential execution.
On many computer operating systems, a computer process terminates its execution by making an exit system call. More generally, an exit in a multithreading environment means that a thread of execution has stopped running. For resource management, the operating system reclaims resources that were used by the process. The process is said to be a dead process after it terminates.
In computer operating systems, a process may wait for another process to complete its execution. In most systems, a parent process can create an independently executing child process. The parent process may then issue a wait system call, which suspends the execution of the parent process while the child executes. When the child process terminates, it returns an exit status to the operating system, which is then returned to the waiting parent process. The parent process then resumes execution.
The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process.
A process is a program in execution, and an integral part of any modern-day operating system (OS). The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronization among processes. To meet these requirements, The OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the operating system to exert control over each process.
Namespaces are a feature of the Linux kernel that partition kernel resources such that one set of processes sees one set of resources, while another set of processes sees a different set of resources. The feature works by having the same namespace for a set of resources and processes, but those namespaces refer to distinct resources. Resources may exist in multiple namespaces. Examples of such resources are process IDs, host-names, user IDs, file names, some names associated with network access, and Inter-process communication.