runc会通过double fork来启动真正的容器进程

  1. /*
  2.  * Okay, so this is quite annoying.
  3.  *
  4.  * In order for this unsharing code to be more extensible we need to split
  5.  * up unshare(CLONE_NEWUSER) and clone() in various ways. The ideal case
  6.  * would be if we did clone(CLONE_NEWUSER) and the other namespaces
  7.  * separately, but because of SELinux issues we cannot really do that. But
  8.  * we cannot just dump the namespace flags into clone(...) because several
  9.  * usecases (such as rootless containers) require more granularity around
  10.  * the namespace setup. In addition, some older kernels had issues where
  11.  * CLONE_NEWUSER wasn't handled before other namespaces (but we cannot
  12.  * handle this while also dealing with SELinux so we choose SELinux support
  13.  * over broken kernel support).
  14.  *
  15.  * However, if we unshare(2) the user namespace *before* we clone(2), then
  16.  * all hell breaks loose.
  17.  *
  18.  * The parent no longer has permissions to do many things (unshare(2) drops
  19.  * all capabilities in your old namespace), and the container cannot be set
  20.  * up to have more than one {uid,gid} mapping. This is obviously less than
  21.  * ideal. In order to fix this, we have to first clone(2) and then unshare.
  22.  *
  23.  * Unfortunately, it's not as simple as that. We have to fork to enter the
  24.  * PID namespace (the PID namespace only applies to children). Since we'll
  25.  * have to double-fork, this clone_parent() call won't be able to get the
  26.  * PID of the _actual_ init process (without doing more synchronisation than
  27.  * I can deal with at the moment). So we'll just get the parent to send it
  28.  * for us, the only job of this process is to update
  29.  * /proc/pid/{setgroups,uid_map,gid_map}.
  30.  *
  31.  * And as a result of the above, we also need to setns(2) in the first child
  32.  * because if we join a PID namespace in the topmost parent then our child
  33.  * will be in that namespace (and it will not be able to give us a PID value
  34.  * that makes sense without resorting to sending things with cmsg).
  35.  *
  36.  * This also deals with an older issue caused by dumping cloneflags into
  37.  * clone(2): On old kernels, CLONE_PARENT didn't work with CLONE_NEWPID, so
  38.  * we have to unshare(2) before clone(2) in order to do this. This was fixed
  39.  * in upstream commit 1f7f4dde5c945f41a7abc2285be43d918029ecc5, and was
  40.  * introduced by 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e. As far as we're
  41.  * aware, the last mainline kernel which had this bug was Linux 3.12.
  42.  * However, we cannot comment on which kernels the broken patch was
  43.  * backported to.
  44.  *
  45.  * -- Aleksa "what has my life come to?" Sarai
  46.  */

parent

parent 进程通过环境变量 _LIBCONTAINER_INITPIPE 获取相关配置信息，然后 clone 出 child 进程，当 child 进程 ready 之后设置 user map，从 child 进程中接受 grandchild 进程 pid，然后通过管道传递给外层的 runc 进程。parent 进程退出条件为 child 进程和 grandchild 都处于 ready 状态后，parent 进程退出。

之所以要 clone child 进程，是因为如果创建了 user namespace，那么 user map 只能由原有的 user namespace 设置，所以需要 clone child 进程，然后在 parent 进程中设置 user map。

child

如果指定了namespace，child 进程会先执行 setns()，加入指定的namespace。

在一些老版本的kernel 中，CLONE_PARENT flag 与 CLONE_NEWPID 有冲突，所以使用 unshare 创建 user namespace， user namespace 需要先于其他 namespace 创建，创建 user namespace 并设置 user map，才有能力创建其他的 namespace。等待 parent 进程设置 user map 后，设置 child 当前进程的 uid 为 root(0) ，使用 unshare 创建其他 namespace，然后 clone grandchild 进程，并将 grandchild 进程 pid 传递给 parent，然后退出。

之所以要 clone grandchild 进程，是因为在 child 进程中设置PID namespace 并不会在 child 进程中生效，所以需要 clone 出一个新的进程，继承 namespace 配置。

grandchild

grandchild 进程就是容器真正的进程，在确保 parent 和 child 进程都处于 ready 之后，设置 uid,gid，从管道中读取相应配置信息，然后 unshare 创建 cgroup namespace，然后将状态发送给 parent 后 返回。grandchild 进程返回后继续执行 go 代码流程。

CLONE flag说明：

如果设置了CLONE_PARENT，子进程的父进程(使用getppid(2)获取)和调用进程的父进程相同。如果没有设置该标志，则子进程的父进程就是调用进程。

如果设置了CLONE_NEWPID ，则会在新的PID命名空间中创建进程。如果没有设置该标志，则新创建的进程与调用进程的PID命名空间相同。