What Are Subreapers In Linux?

This article touches upon zombie and orphan processes, and the corresponding re-parenting from the perspective of a Linux based operating system. It then discusses a relatively newer concept related with re-parenting called subreapers.

Zombie and orphan processes are popular concepts that are commonly discussed among system programmers and operating system developers. So what are zombie processes and why does the kernel maintain them? To answer this question, we have to first understand the basics of process cleanup/termination in the Linux kernel.

In Linux, a process is a running instance of a program or application. It can be seen as an individual task that is being executed on the system. Every process in Linux has a unique process ID (PID), which is a number assigned to it by the operating system. The PID can be used to identify and manage the process. If we close or terminate a program or application, the process exits/terminates.

When a process exits/terminates in Linux, the kernel doesn’t perform the complete clean-up of the process from the memory immediately; instead, its process descriptor stays in the memory. The kernel defers the process clean-up of the child process until its parent/ancestor has reaped the child process via a wait(2) series system call. In order to do this, the kernel updates the child process state as zombie (the kernel maintains the EXIT_ZOMBIE state) and the process’s parent/ancestor is notified that its child process has been terminated/exited via the SIGCHLD signal (refer to the box that follows to know more about SIGCHILD). The parent/ancestor process is then supposed to execute the wait(2) series system call to read the terminated child process’s exit status and other information. This allows the parent process to get information from the exited/terminated child process. After wait(2) is called, the zombie process is marked as a dead process (EXIT_DEAD), and the kernel performs further clean-up and removes the process from the memory.

But what if the parent process didn’t reap its child processes on termination? Well, if the parent process isn’t programmed properly and never calls wait(2) series system calls, the system may be filled with zombie processes. The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait(2) to obtain information about the child. As long as a zombie is not removed from the system via a wait(2) series system call, it will consume a slot in the kernel process table, and if this table fills up, it will not be possible to create further processes.

Orphan processes

As the name suggests, an orphan process is a child process whose parent has exited or been terminated, but the process is still running. In Linux, orphan processes by default re-parent to init(1) processes. Further, the init(1) process will be responsible for reaping the newly re-parented child process. The init(1) process periodically invokes a wait(2) system call for clean-up of all its zombie child processes. However, there are a few exceptions when the orphan processes are not re-parented to init(1). One such case is a multithreaded application (see the box below) and another is a relatively new feature called subreapers, which we will discuss in detail in the sections that follow.

Subreapers

So now we understand that upon termination of a child process, its parent’s responsibility is to reap its child process (by invoking the wait(2) series system call). If the parent terminates/exits before the child process, the kernel re-parents the orphan child process to the init(1) process (in most cases). Now, the init(1) process will further reap the zombie child processes.

Suppose we have an application/daemon process, which forks the multilevel hierarchy of the parent child process— for example, (parent)-(child)-(grandchild), etc. In this case, if the child terminates first, the kernel will re-parent the grandchild to the init(1) process. And when grandchild will exit, init(1) process will further reap the grandchild process. Hence, all the information about the grandchild process will be lost the moment init(1) cleans up the re-parented processes.

To remove such limitations/flaws in the re-parenting approach, Linux kernel 3.4 has modified the prctl(2) system call and implemented a new flag ‘PR_SET_CHILD_SUBREAPER’.

With this modification in the prctl(2) system call, a process can define itself as a subreaper with prctl(PR_SET_CHILD_SUBREAPER). If so, it’s not init(1) that will become the parent of orphaned child processes; instead, the nearest living grandparent that is marked as a subreaper will become the new parent. If there is no living grandparent, init(1) will become the parent.

Please check the prtcl(2) man page for details about the prctl(2) system call and how to set/unset the PR_SET_CHILD_SUBREAPER flag (see the box below).

Now let’s summarise the subreaper concept with a sample program, which will perform the sequence of activities given below:

1. fork() Parent-Child-Grandchild processes
2. Parent will wait(2) for all its descendants
3. Child process will terminate first and grandchild will become orphan
4. Parent will return from wait(2) as child has been exited
5. Kernel will perform the re-parenting of grandchild with init(1)
6. After that, grandchild will terminate
7. Parent process will invoke prctl(2) with PR_SET_CHILD_SUBREAPER flag
8. Parent process will become subreaper
9. Parent will again invoke fork() to create child and grandchild in a similar manner: Parent-Child-Grandchild
10. Parent will wait(2) for all its descendants
11. Child process will terminate first and grandchild will become orphan
12. Parent will return from wait(2) as child has been exited
13. Since the parent process can act as a subreaper, the kernel will re-parent the grandchild process with the parent process
14. After that, grandchild will terminate
15. Parent will return from wait(2) as grandchild (new child) has been exited
16. After that, parent process will also exit

We create a file subreaper.c and type the following code in it:

int fork_grandchild(void)
{
int pid,ppid;
printf (“FORKING GRANDCHILD\n”);
pid = fork();
switch(pid)
{
case -1:
printf(“FORK FAILED\n”);
exit(-1);
case 0:
ppid = getppid();
sleep(2);
printf(“HIERARCHY AFTER CHILD(%d) EXITED\n”,ppid);
printf(“PARENT(%d)===>GRANDCHILD(%d)\n”, getppid(), getpid());
printf(“GRANDCHILD(%d): EXITED\n”, getpid());
exit(0);
default:
return pid;
}
}

int fork_child(void)

{
int pid;
printf (“FORKING CHILD \n”);
pid = fork();
switch(pid)
{
case -1:
printf(“FORK FAILED\n”);
exit(-1);
case 0:
sleep(1);
pid = fork_grandchild();
printf(“INITIAL HIERARCHY\n”);
printf(“ PARENT(%d)===>CHILD(%d)===>GRANDCHILD(%d)\n”,getppid(), getpid(), pid);
sleep(1);
printf(“ CHILD(%d): EXITED\n”, getpid());
exit(0);
default:
return pid;
}
}

void wait_for_descendents()

{
while(1)
{
int pid = wait(NULL);
if(pid == -1)
{
printf(“PARENT(%d): NO MORE CHILD \n”, getpid());
break;
} else
printf(“PARENT(%d)===>CHILD(%d) EXITED\n”, getpid(), pid);

}
}

int main(void)
{
int pid;

printf(“PARENT(%d)\n”, getpid());

pid = fork_child();
printf(“PARENT(%d)====>CHILD(%d)\n”, getpid(), pid);
wait_for_descendents();
sleep(1);

/* set subreaper property*/

prctl(PR_SET_CHILD_SUBREAPER, 1, 0, 0, 0);
printf(“PARENT(%d): I AM SUBREAPER DONT RE PARENT TO INIT\n”, getpid());
pid = fork_child();
printf(“PARENT(%d)====>CHILD(%d)\n”, getpid(), pid);
wait_for_descendents();
printf(“PARENT(%d): exiting \n”, getpid());
return 0;
}

Next, we will compile and execute the above code:

[shwetabh@localhost reaper]$ gcc subreaper.c
[shwetabh@localhost reaper]$ ./a.out
PARENT(31156)
FORKING CHILD
PARENT(31156)====>CHILD(31157)
FORKING GRANDCHILD
INITIAL HIERARCHY
PARENT(31156)===>CHILD(31157)===>GRANDCHILD(31179)
CHILD(31157): EXITED
PARENT(31156)===>CHILD(31157) EXITED
PARENT(31156): NO MORE CHILD
HIERARCHY AFTER CHILD(31157) EXITED
PARENT(1)===>GRANDCHILD(31179) /*init(1) become the parent*/
GRANDCHILD(31179): EXITED
PARENT(31156): I AM SUBREAPER DONT RE PARENT TO INIT
FORKING CHILD
PARENT(31156)====>CHILD(31222)
FORKING GRANDCHILD
INITIAL HIERARCHY
PARENT(31156)===>CHILD(31222)===>GRANDCHILD(31243)
CHILD(31222): EXITED
PARENT(31156)===>CHILD(31222) EXITED
HIERARCHY AFTER CHILD(31222) EXITED
PARENT(31156)===>GRANDCHILD(31243) /*subreaper become the parent */
GRANDCHILD(31243): EXITED
PARENT(31156)===>CHILD(31243) EXITED
PARENT(31156): NO MORE CHILD
PARENT(31156): exiting

I do hope these insights will be helpful in handling zombie and re-parenting related challenges while developing or designing system software.