New parent process when the parent process dies

Three answers written in 2014, all saying that in Unices and in Linux the process is reparented to process #1 without exception. Three wrong answers. ☺

As the SUS says, quoted in one of the other answers here so I won't quote it again, the parent process of orphaned children is set to an implementation-defined process. Cristian Ciupitu is right to consult the Linux documentation to see what the implementation defines. But he is being misled by that documentation, which is inconsistent and not up-to-date.

Two years before these three answers were written, and fast coming up to three years ago at the time of first writing this answer, the Linux kernel changed. The systemd developers added the ability for processes to set themselves up as "subreapers". From Linux 3.4 onwards 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. The man page for prctl() is up-to-date, but other man pages have not been brought up to date and made consistent.

In version 10.2, FreeBSD gained the same ability, extending its existing procctl() system call with PROC_REAP_ACQUIRE and PROC_REAP_RELEASE options. It adopted this mechanism from DragonFly BSD; which gained it in version 4.2, originally named reapctl() but renamed during development to procctl().

So there are exceptions, and fairly prominent ones: On Linux, FreeBSD/PC-BSD, and DragonFly BSD, the parent process of orphaned children is set to the nearest ancestor process of the child that is marked as a subreaper, or process #1 if there is no ancestor subreaper process. Various daemon supervision utilities — including systemd (the one whose developers put this into the Linux kernel in the first place), upstart, and the nosh service-manager — already make use of this.

If such a daemon supervisor is not process #1, and it spawns a service such as an interactive login session, and in that session one does the (quite wrongheaded) trick of attempting to "daemonize" by double-fork()ing, then one's process will end up as a child of the daemon supervisor, not of process #1. Expecting to be able to directly spawn daemons from within login sessions is a fundamental mistake, of course. But that's another answer.

Further reading

• Jonathan Corbet (2012-03-28). 3.4 Merge window part 2. LWN.
• "4. Various core changes". Linux 3.4. Kernel newbies. 2012.
• Daemonizing and Upstart. Nekoconeko. 2014-11-12.
• Lennart Poettering (2012-03-23). prctl: add PR_{SET,GET}_CHILD_SUBREAPER to allow simple process supervision. linux/kernel/git/torvalds/linux.git.
• Matthew Dillon (2014). Add reapctl() system call for managing sub-processes (3) -> procctl(). dragonfly.git.
• procctl(). DragonFly BSD Manual pages. § 2.
• DragonFly BSD 4.2 Release Notes. 2015-07-29.
• Konstantin Belousov (2014-12-01). Process reapers. freebsd-arch mailing list.

According to the exit man page from The Single UNIX® Specification, Version 2:

The parent process ID of all of the calling process' existing child processes and zombie processes is set to the process ID of an implementation-dependent system process. That is, these processes are inherited by a special system process.

For most Unix variants, that special process is init (PID 1).

The Linux wait(2) man page confirms this:

If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies.

The FreeBSD wait(2), NetBSD wait(2), OpenBSD wait(2) and Mac OS X wait(2) man pages confirm this too:

If a parent process terminates without waiting for all of its child processes to terminate, the remaining child processes are assigned the parent process 1 ID (the init process ID).

The Oracle Solaris 11.1 wait(3C) man page confirms this too:

If a parent process terminates without waiting for its child processes to terminate, the parent process ID of each child process is set to 1, with the initialization process inheriting the child processes; see Intro(2).

Moving my comment to an answer.... I don't believe there are exceptions.

Found this "sometimes the parent process is killed before its child is killed. In this case, the "parent of all processes," init process, becomes the new PPID (parent process ID). Sometime these processes are called orphan process." source

Similarly is described in IBM's blog: "The parent dies or gets killed before the child. In the above scenario, the child process becomes the orphan process (as it has lost its parent). In Linux, the init process comes to the rescue of the orphan processes and adopts them. This means after a child has lost its parent, the init process becomes its new parent process."