An orphan process is a computer process whose parent process has finished or terminated, though it remains running itself.
In a Unix-like operating system any orphaned process will be immediately adopted by an implementation-defined system process: the kernel sets the parent to this process. This operation is called re-parenting and occurs automatically. Even though technically the process has a system process as its parent, it is still called an orphan process since the process that originally created it no longer exists. In other systems orphaned processes are immediately terminated by the kernel. Most Unix systems have historically used init as the system process to which orphans are reparented, but in modern DragonFly BSD, FreeBSD, and Linux systems, an orphan process may be reparented to a "subreaper" process instead of init.[1][2]
A process can be orphaned unintentionally, such as when the parent process terminates or crashes. The process group mechanism in most Unix-like operating systems can be used to help protect against accidental orphaning, where in coordination with the user's shell will try to terminate all the child processes with the "hangup" signal (SIGHUP), rather than letting them continue to run as orphans. More precisely, as part of job control, when the shell exits, because it is the "session leader" (its session id equals its process id), the corresponding login session ends, and the shell sends SIGHUP to all its jobs (internal representation of process groups).
It is sometimes desirable to intentionally orphan a process, usually to allow a long-running job to complete without further user attention, or to start an indefinitely running service or agent; such processes (without an associated session) are known as daemons, particularly if they are indefinitely running. A low-level approach is to fork twice, running the desired process in the grandchild, and immediately terminating the child. The grandchild process is now orphaned, and is not adopted by its grandparent, but rather by init. Higher-level alternatives circumvent the shell's hangup handling, either telling the child process to ignore SIGHUP (by using nohup), or removing the job from the job table or telling the shell to not send SIGHUP on session end (by using disown in either case). In any event, the session id (process id of the session leader, the shell) does not change, and the process id of the session that has ended is still in use until all orphaned processes either terminate or change session id (by starting a new session via setsid(2)).
To simplify system administration, it is often desirable to use a service wrapper so that processes not designed to be used as services respond correctly to system signals. An alternative to keep processes running without orphaning them is to use a terminal multiplexer and run the processes in a detached session (or a session that becomes detached), so the session is not terminated and the process is not orphaned.
A server process is also said to be orphaned when the client that initiated the request unexpectedly crashes after making the request while leaving the server process running.
These orphaned processes waste server resources and can potentially leave a server starved for resources. However, there are several solutions to the orphan process problem: