Linux 进程的生命周期

这篇文章将介绍 Linux 中一个进程是如何诞生的,如何结束的。进程有哪些的不同状态,这些状态如何进行转换。

首先我们从进程的基本概念说起。

Linux 中,进程是由父进程创建的,每一个进程又可以作为父进程再创建子进程。每一个进程都有一个ID,叫做 pid,作为进程的唯一标志。Pid 在系统的同一时间不会重复,当分配 pid 的时候,kernel 会取当前系统中最大的 pid + 1,直到这个值超过 /proc/sys/kernel/pid_max ,所以 kernel 不保证 pid 在不同时间不会复用。在进程的结构体里面保存了 ppid,就是父进程的 id。根据 pid 和 ppid 我们可以找到每一个进程的父进程,这样,系统中所有的进程就像一个树一样可以串起来。

通过 pstree 这个工具,我们用一个树展示出所有的进程。

可以看到,最上层的进程的 pid 是 1,其他的进程要么是 pid 1 进程的子进程,要么是 pid 1 子进程的子进程,pid 1 的进程是所有进程的“祖先”。Pid 为 1 的进程,是在 kernel 启动的时候就创建的,所以实际 init 进程没有通常意义上的“父进程”,这里显示出它的父进程是进程0,只是一个标志。

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

  1. /sbin/init: The preferred and most likely location for the init process.
  2. /etc/init: Another likely location for the init process.
  3. /bin/init: A possible location for the init process.
  4. /bin/sh: The location of the Bourne shell, which the kernel tries to run if it fails to find an init process.

除了 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() 出来的进程,和父进程是一模一样的,除了:

  • 子进程的 pid 被重新分配;
  • 子进程的父进程被设置为原来的进程;
  • 子进程资源的统计被初始化成0;
  • 子进程中,未处理的 signal 全部清除;
  • 父进程的 file lock 不会继承到子进程;

那两个进程是一模一样的,我执行了 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 信号;
  • 父进程 block 调用 waitpid() 会返回(即这个系统调用会拿到子进程具体的事件);

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

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

执行这段程序,输出如下:

这段代码执行的流程如下:

子进程在退出之后,保存进程状态的一些信息并不会立即销毁,因为这样的话,父进程就无法获得这些信息了。它们等待父进程调用 wait() 来读出来后,才会真正销毁。

这种已经退出,但是 state change 并没有被父进程读到的进程,叫做讲僵尸进程(Zombies)。父进程创建了子进程,就需要对子进程负责,在子进程退出之后,去调用 wait() 来 clear 这些子进程状态,即使父进程并不关心这些状态是什么。不然的话,这些子进程的状态将一直存在,占用资源(虽然很少),成为 ghosts,这些 ghosts 的 parent 也成为了不负责任的父母。

通常,我们可以安装一个 signal handler 来 wait() 这些子进程。需要注意的是,发给父进程的 SIGCHLD 可能被合并,比如有 3 个子进程退出了,但是父进程实际上只会收到一次 SIGCHLD。所以我们在 wait() 的时候要注意使用一个循环。

 

如果一个进程创建了子进程,但是在子进程之前就退出了呢?这样子进程就没有父进程来调用 wait() 了。

当一个进程结束的时候,kernel 会遍历它的子进程,将这些父进程已经死掉的进程,分配给 init 进程(即 pid 是1的进程)作为它们的父进程。这就保证了系统中每一个进程,都有一个直接的父进程。init 进程会定期去 wait() 它所有的子进程。

进程的状态

上面我们已经提到了一些进程的状态:Zombies,Runing,Stopped。

这里重点解释一下几种状态:

  • R – runnable,处于这个状态的进程是可以执行的,会被 kernel 放到一个待执行的 queue 中,分配时间片去执行。我们无法控制进程的运行,runnable 的进程由 kernel 的 scheduler 来决定什么时候运行,运行多长时间;
  • D – 不可中断的 sleep(一般是IO);
  • S – 可中断的 sleep;
  • Z – 进程已死,或者失去响应,死透了;
  • T – 进程以暂停(是可以恢复的,还没死透);

这里面其他状态都比较好理解,D 和 S 有点模糊。

代码在执行的时候,会在 user space 和 kernel space 之间切换。当执行 syscall 的时候,代码的执行从用户空间切换到内核空间。当在等待 system call 的时候,进程处于 S 状态或者 D 状态。S 状态比如 read() ,这时收到像 SIGTERM 这样的信号,进程就会提前结束 syscall,返回用户空间,执行 signal hanlder 的代码;如果是处于 D 状态,进程就是不可 kill 的

T 状态是可以恢复的暂停。比如我们给进程发送 SIGSTOP 或者按 CTRL+Z,就可以将进程置为暂停状态,可以通过 bg/fg 命令,或者发送 SIGCONT 信号恢复。

下面开启了一个 sleep 命令,然后用 CTRL+Z 暂停它,再用 fg 重新开启。展示了 S -> T -> S 的状态转换:

将 sleep 命令替换成 yes > /dev/null ,上面实验的状态 S 会变成 R,其他一样。

综上,状态流转如下(再盗图一张):

所有的进程状态,可以看下这个文档,介绍了源代码中定义的进程状态。

信号

上面介绍了一些信号,这里再列一些常用的:

  • SIGCHLD:子进程状态改变;
  • SIGCONT: 进程继续执行;
  • SIGSTOP: 进程暂停,和上面的 SIGCONT 是一对;
  • SIGTERM: 指示进程结束,这个信号可以被捕捉或者忽略,允许进程收到这个信号之后 gracefully exit;
  • SIGKILL: 立即结束进程,收到这个信号的进程无法忽略这个信号,必须退出。但是 init 除外,init 不接受 SIGKILL;
  • SIGINT: 从终端(用 CTRL+C)发出的终端信号。在一些 REPL 中会介绍当前的命令,也有些进程的表现是直接退出;

信号本质上是一中进程间通讯方式(IPC),Signal wiki

 

以上就是基本的进程知识了,本文所有的参考资料已经在文中链接。这是我最近读 Linux System Programming 的笔记,如有理解错误,请指出。接下来还会分享一些有关 Linux 的文章。

Linux 进程的生命周期”已经有3条评论

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注