Pid 为 1 的进程是可以指定的，我这个 系统中是 systemd 。如果不指定的话，Kernel 将尝试以下 4 个可执行文件：

除了 pid 为 1 的进程外，其实还有一个 pid 为 2 的进程，父进程也是 0. 这个进程叫 kthreadd。

同理，这个进程也是在 Kernel 启动的时候就创建的。Linux 中有一些进程是 跑在 Kernel 中的，但是为了统一调度，这些进程也同用户进程一样放在一起管理。 kthreadd 就是这些 kernel 进程的父进程 ，等同于 init 进程（或者 systemd 进程）之于我们的用户进程。

Pid 0可以认为就是 kernel 本身。这个进程也是 idel process，当没有可以运行的进程的时候，kernel 就运行进程 0.

那么一个进程是如何产生自己的子进程的呢？

在 Unix 中，创建进程和载入要执行的程序是分开的。创建一个进程一共2步，涉及2个 syscall。

第一个是 fork() ，负责创建出来一个新的进程。那么新的进程也需要有可执行的代码、地址空间啥的呀，默认是啥呢？总不能是空的吧，如果是空的，那 kernel 执行到这个进程怎么办？

答案是 fork() 出来的进程，和父进程是一模一样的，除了：

那两个进程是一模一样的，我执行了 fork() 之后，怎么让这两个进程做不一样的事情呢？答案是 fork() 的返回值不同， fork() 在父进程中返回子进程的 pid，在子进程中返回 0.这样我们就可以在调用 fork() 之后，通过一个 if 判断，让子进程和父进程做不一样的事情。一般是下面这种代码模板：

新的进程创建好了，我们想让新的进程去执行另一部分任务，但是无法像上面这样都写在代码中，怎么办呢？举个很好理解的场景，我在终端的 bash 中执行了一个 top 命令，那么 bash 的代码肯定是和 top 没有关系的，怎么让 bash 新创建的子进程去执行 top 的代码吗？

这就是载入部分了。载入的 syscall 是一个函数族，这里用调用最简单的 execl() 举例：

有关 execl 具体的行为，可以参考下 manual.  exec 是一个 syscall family，除了 execl() 这个之外，还有：execl, execlp, execle, execv, execvp, execvpe。本质上他们都一样，只是传入参数的格式、path、环境变量有些许不同。这些函数都是 glibc 提供的库函数（其他的 C 库提供的会有所不同，比如 libc 提供的函数族就是 execl, execle, execlp, execv, execvp, execvP ），底层他们调用的都是 execve（感谢 Nitroethane 指正）。

通常，打开的文件可以通过 exec 继承。比如父进程打开了一个文件，那么父进程的子进程是有 full access 的。如果不想这么做的话，可以在 exec 之前关闭这些文件。

Copy-on-write

在早期的 Unix 系统中， fork() 之后要复制很多东西到子进程，最耗时的是要一个 page 一个 page 地拷贝内存，这个操作非常耗时。

现代的 Unix 系统中，有一种叫做 copy-on-write 的机制。本质上是对这种资源复制的优化策略：如果多个消费者都需要一段内存的副本的话，先不去真正的做拷贝，而是让这些消费者都认为自己持有这段内存。如果进行读操作，那其实大家读到的还是同一段内存；如果要进行写操作，那这段内存（以 page 为单位）就会透明地被 kernel 拷贝出来。所以是一种懒加载的策略，只有用到的时候才去拷贝。

fork() 可以说是这个机制的最大受益者，因为 fork() 之后经常跟的是 exec ，也就是说子进程被 fork 出来之后都去干别的了，你复制一遍父进程的内存过来也没有意义。

这里我还想提一下，Redis 的 rdb 机制也是 copy-on-write 的一大受益者。Redis 的 rdb 就是定期将 Redis 内存中存储的数据转存到硬盘上，这个功能是基于 fork 实现的：当 Reids 要要 dump rdb 的时候，先 fork 出一个子进程，然后子进程开始从内存读出来数据，写到硬盘上，而原来的进程（父进程）继续提供服务。得益于 copy-on-write，子进程不需要完全复制一份父进程的内存来做写硬盘操作，即节省了时间和CPU，也节省了内存——它和父进程读的是同一段内存。

但是这里有个问题就是，假如 Reids 用在了一个写操作非常频繁的场景的话，那 copy-on-write 的意义就不大了。子进程 fork 出来之后，父进程因为写入很频繁，大部分内存都脏了，都需要被 kernel copy 出一份进行写操作。就可能导致在 dump rdb 的时候，内存占用提升了一倍（子进程和父进程分别有一份内存）。

一个进程要结束自己，非常简单。调用 exit() 这个 syscall，kernel 就会结束这个函数的调用者进程。我们也可以通过 atexit() 或 on_exit() 函数注册一些进程退出时的 hook。

除了显示的调用 exit() 之外，一个经典的退出方式是执行完整个程序。比如 main() 函数的代码最后，编译器会插入一个 _exit() 。

进程收到 SIGTERM 或 SIGKILL 之后也会退出。具体的 signal 下面会介绍。

最后一种结束进程的方式是，惹的 kernel 不高兴了。比如出现 OOM 了（out-of-memory），或者 segment fault。kernel 会结束这个进程。

子进程退出之后，谁关心子进程是如何退出的呢？比如 daemon 进程退出了，systemd 如何实现“restart on failure”呢？所以这里还需要某种机制，来关心子进程的退出状态。

当子进程的状态改变之后，父进程会发生2件事情：

也就是说父进程如果关心子进程的状态的话，一般是会设置 SIGCHLD 信号的 handler（进程如何处理信号，本文暂不涉及），收到这个信号之后去调用 wait() 系统调用，得到具体的事件。

这里 有一个 Python 写的例子，展示了父进程如何得到子进程的状态。