What is PID 1

The top-most process in a UNIX system has PID (Process ID) 1 and is usually the init process. The Init process is the first userspace application started on a system and is started by the kernel at boottime. The kernel is looking in a few predefined paths (and the init kernel parameter). If no such application is found, the system will panic().

See init/main.c:kernel_init :

1if (!try_to_run_init_process("/sbin/init") ||
2    !try_to_run_init_process("/etc/init") ||
3    !try_to_run_init_process("/bin/init") ||
4    !try_to_run_init_process("/bin/sh"))
5    return 0;
6panic("No working init found.  Try passing init= option to kernel. "
7      "See Linux Documentation/admin-guide/init.rst for guidance.");

All processes in UNIX has a parent/child relationship which builds up a big relationship-tree. Some resources and permissions are inherited from parent to child. Example on such resources are UID and cgroup restrictions.

As in the real world, with parenthood comes obligations. For example: What is usually the last line of your main()-function? Hopfully something like :

1return EXIT_SUCCESS;

All processes exits with an exit code that tells us if the operation was sucessful or not. But who is interested in this exit code anyway?

In the real world, the parents are interested in their children's result, and so even here. The parent is responsible to wait(2) on their children to terminate just to fetch its exit code. But what if the parent died before the child?

Lets go back to the init process.

The init process has several tasks, and one is to adopt "orphaned" (called zombie) child processes. Why? Because all processes will return an exit code and will not terminate completely until someone is listen for what they have to say. The init process is simply wait(2):ing on the exit code, throw it away and let the child die. Sad but true, but the child may not rest i peace otherwise. The operating system expects the init process to reap adopted children. Otherwise the children will exist in the system as a zombie and taking up some kernel resources and consume a slot in the kernel process table.

PID 1 in containers

Containers is a concept that isolate processes in different namespaces. Example of such namespaces are PID, users, networking and filesystem. To create a container is quite simple, just create a new process with clone(2) and provide relevant flags to create new namespaces for the process.

The flags related to namespaces are listed in include/uapi/linux/sched.h:

1#define CLONE_NEWPID		0x20000000	// New pid namespace
2#define CLONE_NEWCGROUP		0x02000000	// New cgroup namespace
3#define CLONE_NEWUTS		0x04000000	// New utsname namespace
4#define CLONE_NEWIPC		0x08000000	// New ipc namespace
5#define CLONE_NEWUSER		0x10000000	// New user namespace
6#define CLONE_NEWPID		0x20000000	// New pid namespace
7#define CLONE_NEWNET		0x40000000	// New network namespace

All processes is running in a "container-context" because the processes allways executes in a namespace. On a system "without containers", all processes still have one common namespace that all processes is using.

When using CLONE_NEWPID, the kernel will create a new PID namespace and let the newly created process has the PID 1. As we already know, the PID 1 process has a very special task, namely to kill all orphaned children. This PID 1 process could be any application (make, bash, nginx, ftp-server or whatever) that is missing this essential adopt-and-slay-mechanism.

If the reaping is not handled, it will result in zombie-processes. This was a real problem not long time ago for Docker containers (google Docker and zombies to see what I mean). Nowadays we have the --init flag on docker run to tell the container to use tini (https://github.com/krallin/tini), a zombie-reaping init process to run with PID 1.

When PID 1 dies

This is the reason to why I'm writing this post. I was wondering who is killing PID 1 in a container since we learned that a PID 1 may not die under any circumstances. PID 1 in cointainers is obviously an exception from this golden rule, but how does the kernel differentiate between init processes in different PID namespaces?

Lets follow a process to its very last breath.

The call chain we will look at is the following: do_exit() -> exit_notify() -> forget_original_parent() -> find_child_reaper().

 1    ......
 2
 3    <<<<< Collect exit code >>>>>
 4    tsk->exit_code = code; 
 5    taskstats_exit(tsk, group_dead);
 6    
 7
 8    exit_mm(tsk);
 9
10    if (group_dead)
11        acct_process();
12    trace_sched_process_exit(tsk);
13
14    <<<<< Free up resources >>>>>
15    exit_sem(tsk);
16    exit_shm(tsk);
17    exit_files(tsk);
18    exit_fs(tsk);
19    if (group_dead)
20        disassociate_ctty(1);
21    exit_task_namespaces(tsk);
22    exit_task_work(tsk);
23    exit_thread(tsk);
24
25    perf_event_exit_task(tsk);
26
27    sched_autogroup_exit_task(tsk);
28    cgroup_exit(tsk);
29
30    <<<<< Notify tasks in the same group >>>>>
31    exit_notify(tsk, group_dead);
32    
33    .........

1\*\*
2\* A maximum of 4 million PIDs should be enough for a while.
3\* [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.]
4\*/
5#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
6(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

1    static void exit_notify(struct task_struct *tsk, int group_dead)
2    {
3        bool autoreap;
4        struct task_struct *p, *n;
5        LIST_HEAD(dead);
6
7        write_lock_irq(&tasklist_lock);
8      >>>>>  forget_original_parent(tsk, &dead);

1        >>>>> reaper = find_child_reaper(father);
2        if (list_empty(&father->children))
3            return;

1    if (unlikely(pid_ns == &init_pid_ns)) {
2        panic("Attempted to kill init! exitcode=0x%08x\n",
3            father->signal->group_exit_code ?: father->exit_code);
4    }
5    zap_pid_ns_processes(pid_ns);

 1    nr = next_pidmap(pid_ns, 1);
 2    while (nr > 0) {
 3
 4        rcu_read_lock();
 5
 6        task = pid_task(find_vpid(nr), PIDTYPE_PID);
 7        if (task && !__fatal_signal_pending(task))
 8        >>>>> send_sig_info(SIGKILL, SEND_SIG_FORCED, task);
 9
10        rcu_read_unlock();
11
12        nr = next_pidmap(pid_ns, nr);
13
14    }

Conclusion

The PID 1 in containers is handled in a seperate way than the real init process. This is obvious, but now we know where the codeflow differ for PID 1 in different namespaces.

We also see that if the PID1 in a PID namespace dies, all the subprocesses will be terminated with SIGKILL. This behavior reflects the fact that the init process is essential for the correct operation of any PID namespace.