Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

In UNIX, when a parent process disappears, I thought that all child processes reset init as their parent. Is this not correct all the time? Are there any exceptions?

share|improve this question

4 Answers 4

up vote 3 down vote accepted

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 chile has lost its parent, the init process becomes its new parent process."

share|improve this answer

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 doco to see what the implementation defines. But xe is being misled by that doco, 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 grandchildren 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 grandparent process of the child that is marked as a subreaper, or process #1 if there is no grandparent subreaper process. Various dæmon 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 dæmon 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 "dæmonize" by double-fork()ing, then one's process will end up as a child of the dæmon supervisor, not of process #1. Expecting to be able to directly spawn dæmons from within login sessions is a fundamental mistake, of course. But that's another answer.

Further reading

share|improve this answer
I had actually noticed orphan processes getting attached to a session init (on Ubuntu with Upstart), but never realised its significance. +1 – muru Apr 20 at 23:57
See for more on upstart session init, specifically. – JdeBP Apr 21 at 7:10

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).

share|improve this answer

I don't believe so. It always goes to the init process.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.