What Happens to Child Process

Are child processes created with fork() automatically killed when the parent is killed?

No. If the parent is killed, children become children of the init process (that has the process id 1 and is launched as the first user process by the kernel).

The init process checks periodically for new children, and waits for them (thus freeing resources that are allocated by their return value).

The question was already discussed with quality answers here:
How to make child process die after parent exits?

How to make child process die after parent exits?

Child can ask kernel to deliver SIGHUP (or other signal) when parent dies by specifying option PR_SET_PDEATHSIG in prctl() syscall like this:

prctl(PR_SET_PDEATHSIG, SIGHUP);

See man 2 prctl for details.

Edit: This is Linux-only

What happen when a child process encounter a wait instruction?

It will return -1 and set errno to ECHILD since the child process has no children of its own to wait on. From the wait(2) man page:

Return value

• wait(): on success, returns the process ID of the terminated
  child; on error, -1 is returned.

• ...

Each of these calls sets errno to an appropriate value in the case of an error.

Errors

• ECHILD (for wait())
  
  The calling process does not have any unwaited-for children.

• ...

---

Note that the logic here is backwards from the norm:

if (pid > 0) {
    execv(*argv, argv); 
}

Here the parent process is calling execv(). Usually it's the child that does so when pid == 0, and it's the parent that waits.

What happens when first child process exits, then parent exits without calling wait?

It gets reparented (adopted) by init. Yes, you'll see a zombie process until init calls wait()--but init calls wait() straightaway, so you're never going to catch the zombie process in practice. init is very good about immediately reaping zombie processes reparented to it.

What happens to the child process, when the parent process calls an exec command

The pid of the parent process will remain the same after the exec, so the process hierarchy won't be affected.

The problem with this approach is that the newly replaced parent process generally won't be aware that it has previously spawned a child and will not call wait or waitpid on it. This will cause the child process to become a zombie when it exits.

What if the child exits before the parent calls wait()?

But what if the kernel decides to schedule the child first and the
child process terminates before parent can call the wait()?

It is a pretty possible case. If one of the wait family functions is used by the parent or signal(SIGCHLD, SIG_IGN); is called explicitly before forking, it does not turn the child into a zombie even if the parent process is preempted(=not permitted to use CPU at that time).

Moreover, the need of wait or signal-ignorance mentioned is to clean process's unused datas. While using one of the methods, the kernel is told that the child(ren) process is not used anymore. So, you can cleanup unused system resources.

---

Related Topics