问题的症状

用户直接在微信里说，他们发现在Kuberbnetes下的某个pod被重启了几百次甚至上千次，于是开启调查这个pod，发现上面的服务时而能够访问，时而不能访问，也就是有一定概率不能访问，不知道是什么原因。而且并不是所有的pod出问题，而只是特定的一两个pod出了网络访问的问题。用户说这个pod运行着Java程序，为了排除是Java的问题，用户用 docker exec -it 命令直接到容器内启了一个 Python的 SimpleHttpServer来测试发现也是一样的问题。

我们大概知道用户的集群是这样的版本，Kuberbnetes 是1.7，网络用的是flannel的gw模式，Docker版本未知，操作系统CentOS 7.4，直接在物理机上跑docker，物理的配置很高，512GB内存，若干CPU核，上面运行着几百个Docker容器。

问题的排查

问题初查

首先，我们排除了flannel的问题，因为整个集群的网络通信都正常，只有特定的某一两个pod有问题。而用 telnet ip port 的命令手工测试网络连接时有很大的概率出现 connection refused 错误，大约 1/4的概率，而3/4的情况下是可以正常连接的。

当时，我们让用户抓个包看看，然后，用户抓到了有问题的TCP连接是收到了 SYN 后，立即返回了 RST, ACK

我问一下用户这两个IP所在的位置，知道了，10.233.14.129 是 docker0，10.233.14.145 是容器内的IP。所以，这基本上可以排除了所有和kubernets或是flannel的问题，这就是本地的Docker上的网络的问题。

对于这样被直接 Reset 的情况，在 telnet 上会显示 connection refused 的错误信息，对于我个人的经验，这种 SYN完直接返回 RST, ACK的情况只会有三种情况：

1.  TCP链接不能建立，不能建立连接的原因基本上是标识一条TCP链接的那五元组不能完成，绝大多数情况都是服务端没有相关的端口号。
2. TCP链接建错误，有可能是因为修改了一些TCP参数，尤其是那些默认是关闭的参数，因为这些参数会导致TCP协议不完整。
3. 有防火墙iptables的设置，其中有 REJECT 规则。

因为当时还在开车，在等红灯的时候，我感觉到有点像 NAT 的网络中服务端开启了 tcp_tw_recycle 和 tcp_tw_reuse 的症况（详细参看《TCP的那些事（上）》），所以，让用户查看了一上TCP参数，发现用户一个TCP的参数都没有改，全是默认的，于是我们排除了TCP参数的问题。

然后，我也不觉得容器内还会设置上iptables，而且如果有那就是100%的问题，不会时好时坏。所以，我怀疑容器内的端口号没有侦听上，但是马上又好了，这可能会是应用的问题。于是我让用户那边看一下，应用的日志，并用 kublet describe看一下运行的情况，并把宿主机的 iptables 看一下。

然而，我们发现并没有任何的问题。这时，我们失去了所有的调查线索，感觉不能继续下去了……

重新梳理

这个时候，回到家，大家吃完饭，和用户通了一个电话，把所有的细节再重新梳理了一遍，这个时候，用户提供了一个比较关键的信息—— “抓包这个事，在 docker0 上可以抓到，然而到了容器内抓不到容器返回 RST, ACK ” ！然而，根据我的知识，我知道在 docker0 和容器内的 veth 网卡上，中间再也没有什么网络设备了（参看《Docker基础技术：LINUX NAMESPACE（下）》）!

于是这个事把我们逼到了最后一种情况 —— IP地址冲突了！

Linux下看IP地址冲突还不是一件比较简单事的，而在用户的生产环境下没有办法安装一些其它的命令，所以只能用已有的命令，这个时候，我们发现用户的机器上有 arping 于是我们用这个命令来检测有没有冲突的IP地址。使用了下面的命令：

$ arping -D -I docker0 -c 2 10.233.14.145
$ echo $?

根据文档，-D 参数是检测IP地址冲突模式，如果这个命令的退状态是 0 那么就有冲突。结果返回了 1 。而且，我们用 arping IP的时候，没有发现不同的mac地址。 这个时候，似乎问题的线索又断了。

因为客户那边还在处理一些别的事情，所以，我们在时断时续的情况下工作，而还一些工作都需要用户完成，所以，进展有点缓慢，但是也给我们一些时间思考问题。

柳暗花明

现在我们知道，IP冲突的可能性是非常大的，但是我们找不出来是和谁的IP冲突了。而且，我们知道只要把这台机器重启一下，问题一定就解决掉了，但是我们觉得这并不是解决问题的方式，因为重启机器可以暂时的解决掉到这个问题，而如果我们不知道这个问题怎么发生的，那么未来这个问题还会再来。而重启线上机器这个成本太高了。

于是，我们的好奇心驱使我们继续调查。我让用户 kubectl delete 其中两个有问题的pod，因为本来就服务不断重启，所以，删掉也没有什么问题。删掉这两个pod后（一个是IP为 10.233.14.145 另一个是 10.233.14.137），我们发现，kubernetes在其它机器上重新启动了这两个服务的新的实例。然而，在问题机器上，这两个IP地址居然还可以ping得通。

好了，IP地址冲突的问题可以确认了。因为10.233.14.xxx 这个网段是 docker 的，所以，这个IP地址一定是在这台机器上。所以，我们想看看所有的 network namespace 下的 veth 网卡上的IP。

在这个事上，我们费了点时间，因为对相关的命令也 很熟悉，所以花了点时间Google，以及看相关的man。

• 首先，我们到 /var/run/netns目录下查看系统的network namespace，发现什么也没有。
• 然后，我们到 /var/run/docker/netns 目录下查看Docker的namespace，发现有好些。
• 于是，我们用指定位置的方式查看Docker的network namespace里的IP地址

这里要动用 nsenter 命令，这个命令可以进入到namespace里执行一些命令。比如

$ nsenter --net=/var/run/docker/netns/421bdb2accf1 ifconfig -a

上述的命令，到 var/run/docker/netns/421bdb2accf1 这个network namespace里执行了 ifconfig -a 命令。于是我们可以用下面 命令来遍历所有的network namespace。

$ ls /var/run/docker/netns | xargs -I {} nsenter --net=/var/run/docker/netns/{} ip addr 

然后，我们发现了比较诡异的事情。

• 10.233.14.145 我们查到了这个IP，说明，docker的namespace下还有这个IP。
• 10.233.14.137，这个IP没有在docker的network namespace下查到。

有namespace leaking？于是我上网查了一下，发现了一个docker的bug – 在docker remove/stop 一个容器的时候，没有清除相应的network namespace，这个问题被报告到了 Issue#31597 然后被fix在了 PR#31996，并Merge到了 Docker的 17.05版中。而用户的版本是 17.09，应该包含了这个fix。不应该是这个问题，感觉又走不下去了。

不过， 10.233.14.137 这个IP可以ping得通，说明这个IP一定被绑在某个网卡，而且被隐藏到了某个network namespace下。

到这里，要查看所有network namespace，只有最后一条路了，那就是到 /proc/ 目录下，把所有的pid下的 /proc/<pid>/ns 目录给穷举出来。好在这里有一个比较方便的命令可以干这个事 ： lsns

于是我写下了如下的命令：

$ lsns -t net | awk ‘{print $4}' | xargs -t -I {} nsenter -t {} -n ip addr | grep -C 4 "10.233.14.137"

解释一下。

• lsns -t net 列出所有开了network namespace的进程，其第4列是进程PID
• 把所有开过network namespace的进程PID拿出来，转给 xargs 命令
• 由 xargs 命令把这些PID 依次传给 nsenter 命令，
  • xargs -t 的意思是会把相关的执行命令打出来，这样我知道是那个PID。
  • xargs -I {}  是声明一个占位符来替换相关的PID

最后，我们发现，虽然在 /var/run/docker/netns 下没有找到 10.233.14.137 ，但是在 lsns 中找到了三个进程，他们都用了10.233.14.137 这个IP（冲突了这么多），而且他们的MAC地址全是一样的！（怪不得arping找不到）。通过ps 命令，可以查到这三个进程，有两个是java的，还有一个是/pause （这个应该是kubernetes的沙盒）。

我们继续乘胜追击，穷追猛打，用pstree命令把整个进程树打出来。发现上述的三个进程的父进程都在多个同样叫 docker-contiane 的进程下！

这明显还是docker的，但是在docker ps 中却找不道相应的容器，什么鬼！快崩溃了……

继续看进程树，发现，这些 docker-contiane 的进程的父进程不在 dockerd 下面，而是在 systemd 这个超级父进程PID 1下，我靠！进而发现了一堆这样的野进程（这种野进程或是僵尸进程对系统是有害的，至少也是会让系统进入亚健康的状态，因为他们还在占着资源）。

docker-contiane 应该是 dockerd 的子进程，被挂到了 pid 1 只有一个原因，那就是父进程“飞”掉了，只能找 pid 1 当养父。这说明，这台机器上出现了比较严重的 dockerd 进程退出的问题，而且是非常规的，因为 systemd 之所以要成为 pid 1，其就是要监管所有进程的子子孙孙，居然也没有管理好，说明是个非常规的问题。（注，关于 systemd，请参看《Linux PID 1 和 Systemd 》，关于父子进程的事，请参看《Unix高级环境编程》一书）

接下来就要看看 systemd 为 dockerd 记录的日志了…… （然而日志只有3天的了，这3天dockerd没有任何异常）

总结

通过这个调查，可以总结一下，

1） 对于问题调查，需要比较扎实的基础知识，知道问题的成因和范围。

2）如果走不下去了，要重新梳理一下，回头仔细看一下一些蛛丝马迹，认真推敲每一个细节。

3） 各种诊断工具要比较熟悉，这会让你事半功倍。

4）系统维护和做清洁比较类似，需要经常看看系统中是否有一些僵尸进程或是一些垃圾东西，这些东西要及时清理掉。

最后，多说一下，很多人都说，Docker适合放在物理机内运行，这并不完全对，因为他们只考虑到了性能成本，没有考虑到运维成本，在这样512GB中启动几百个容器的玩法，其实并不好，因为这本质上是个大单体，因为你一理要重启某些关键进程或是机器，你的影响面是巨大的。

———————— 更新 2018/12/10 —————————

问题原因

这两天在自己的环境下测试了一下，发现，只要是通过 systemctl start/stop docker 这样的命令来启停 Docker， 是可以把所有的进程和资源全部干掉的。这个是没有什么问题的。我唯一能重现用户问题的的操作就是直接 kill -9 <dockerd pid> 但是这个事用户应该不会干。而 Docker 如果有 crash 事件时，Systemd 是可以通过 journalctl -u docker 这样的命令查看相关的系统日志的。

于是，我找用户了解一下他们在Docker在启停时的问题，用户说，他们的执行 systemctl stop docker 这个命令的时候，发现这个命令不响应了，有可能就直接按了 Ctrl +C 了！

这个应该就是导致大量的 docker-containe 进程挂到 PID 1 下的原因了。前面说过，用户的一台物理机上运行着上百个容器，所以，那个进程树也是非常庞大的，我想，停服的时候，系统一定是要遍历所有的docker子进程来一个一个发退出信号的，这个过程可能会非常的长。导致操作员以为命令假死，而直接按了 Ctrl + C ，最后导致很多容器进程并没有终止……

其它事宜

有同学问，为什么我在这个文章里写的是 docker-containe 而不是 containd 进程？这是因为被 pstree 给截断了，用 ps 命令可以看全，只是进程名的名字有一个 docker-的前缀。

下面是这两种不同安装包的进程树的差别（其中 sleep 是我用 buybox 镜像启动的）

systemd───dockerd─┬─docker-contained─┬─3*[docker-contained-shim─┬─sleep]
                  │                 │                    └─9*[{docker-containe}]]
                  │                 ├─docker-contained-shim─┬─sleep
                  │                 │                 └─10*[{docker-containe}]
                  │                 └─14*[{docker-contained-shim}]
                  └─17*[{dockerd}]

systemd───dockerd─┬─containerd─┬─3*[containerd-shim─┬─sleep]
                  │            │                 └─9*[{containerd-shim}]
                  │            ├─2*[containerd-shim─┬─sleep]
                  │            │                    └─9*[{containerd-shim}]]
                  │            └─11*[{containerd}]
                  └─10*[{dockerd}]

顺便说一下，自从 Docker 1.11版以后，Docker进程组模型就改成上面这个样子了.

• dockerd 是 Docker Engine守护进程，直接面向操作用户。dockerd 启动时会启动 containerd 子进程，他们之前通过RPC进行通信。
• containerd 是dockerd和runc之间的一个中间交流组件。他与 dockerd 的解耦是为了让Docker变得更为的中立，而支持OCI 的标准 。
• containerd-shim  是用来真正运行的容器的，每启动一个容器都会起一个新的shim进程， 它主要通过指定的三个参数：容器id，boundle目录（containerd的对应某个容器生成的目录，一般位于：/var/run/docker/libcontainerd/containerID）， 和运行命令（默认为 runc）来创建一个容器。
• docker-proxy 你有可能还会在新版本的Docker中见到这个进程，这个进程是用户级的代理路由。只要你用 ps -elf 这样的命令把其命令行打出来，你就可以看到其就是做端口映射的。如果你不想要这个代理的话，你可以在 dockerd 启动命令行参数上加上：  --userland-proxy=false 这个参数。

更多的细节，大家可以自行Google。这里推荐两篇文章：

• Docker, Containerd & Standalone Runtimes — Here’s What You Should Know
• Docker components explained

（全文完）

SysV Init

PID 1 这个进程非常特殊，其主要就任务是把整个操作系统带入可操作的状态。比如：启动 UI – Shell 以便进行人机交互，或者进入 X 图形窗口。传统上，PID 1 和传统的 Unix System V 相兼容的，所以也叫 sysvinit，这是使用得最悠久的 init 实现。Unix System V 于1983年 release。

在 sysvint 下，有好几个运行模式，又叫 runlevel。比如：常见的 3 级别指定启动到多用户的字符命令行界面，5 级别指定启起到图形界面，0 表示关机，6 表示重启。其配置在 /etc/inittab 文件中。

与此配套的还有 /etc/init.d/ 和 /etc/rc[X].d，前者存放各种进程的启停脚本（需要按照规范支持 start，stop子命令），后者的 X 表示不同的 runlevel 下相应的后台进程服务，如：/etc/rc3.d 是 runlevel=3 的。 里面的文件主要是 link 到  /etc/init.d/ 里的启停脚本。其中也有一定的命名规范：S 或 K 打头的，后面跟一个数字，然后再跟一个自定义的名字，如：S01rsyslog，S02ssh。S 表示启动，K表示停止，数字表示执行的顺序。

UpStart

Unix 和 Linux 在 sysvint 运作多年后，大约到了2006年的时候，Linux内核进入2.6时代，Linux有了很多更新。并且，Linux开始进入桌面系统，而桌面系统和服务器系统不一样的是，桌面系统面临频繁重启，而且，用户会非常频繁的使用硬件的热插拔技术。于是，这些新的场景，让 sysvint 受到了很多挑战。

比如，打印机需要CUPS等服务进程，但是如果用户没有打机印，启动这个服务完全是一种浪费，而如果不启动，如果要用打印机了，就无法使用，因为sysvint 没有自动检测的机制，它只能一次性启动所有的服务。另外，还有网络盘挂载的问题。在 /etc/fstab 中，负责硬盘挂载，有时候还有网络硬盘（NFS 或 iSCSI）在其中，但是在桌面机上，有很可能开机的时候是没有网络的， 于是网络硬盘都不可以访问，也无法挂载，这会极大的影响启动速度。sysvinit 采用 netdev 的方式来解决这个问题，也就是说，需要用户自己在 /etc/fstab 中给相应的硬盘配置上 netdev 属性，于是 sysvint 启动时不会挂载它，只有在网络可用后，由专门的 netfs 服务进程来挂载。这种管理方式比较难以管理，也很容易让人掉坑。

所以，Ubuntu 开发人员在评估了当时几个可选的 init 系统后，决定重新设计这个系统，于是，这就是我们后面看到的 upstart 。 upstart 基于事件驱动的机制，把之前的完全串行的同步启动服务的方式改成了由事件驱动的异步的方式。比如：如果有U盘插入，udev 得到通知，upstart 感知到这个事件后触发相应的服务程序，比如挂载文件系统等等。因为使用一个事件驱动的玩法，所以，启动操作系统时，很多不必要的服务可以不用启动，而是等待通知，lazy 启动。而且事件驱动的好处是，可以并行启动服务，他们之间的依赖关系，由相应的事件通知完成。

upstart 有着很不错的设计，其中最重要的两个概念是 Job 和 Event。

Job 有一般的Job，也有service的Job，并且，upstart 管理了整个 Job 的生命周期，比如：Waiting, Starting, pre-Start, Spawned, post-Start, Running, pre-Stop, Stopping, Killed, post-Stop等等，并维护着这个生命周期的状态机。

Event 分成三类，signal, method 和 hooks。signal 就是异步消息，method 是同步阻塞的。hooks 也是同步的，但介于前面两者之间，发出hook事件的进程必须等到事件完成，但不检查是否成功。

但是，upstart 的事件非常复杂，也非常纷乱，各种各样的事件（事件没有归好类）导致有点凌乱。不过因为整个事件驱动的设计比之前的 sysvinit 来说好太多，所以，也深得欢迎。

Systemd

直到2010的有一天，一个在 RedHat工作的工程师 Lennart Poettering 和 Kay Sievers ，开始引入了一个新的 init 系统—— systemd。这是一个非常非常有野心的项目，这个项目几乎改变了所有的东西，systemd 不但想取代已有的 init 系统，而且还想干更多的东西。

Lennart 同意 upstart 干的不错，代码质量很好，基于事件的设计也很好。但是他觉得 upstart 也有问题，其中最大的问题还是不够快，虽然 upstart 用事件可以达到一定的启动并行度，但是，本质上来说，这些事件还是会让启动过程串行在一起。  如：NetworkManager 在等 D-Bus 的启动事件，而 D-Bus 在等 syslog 的启动事件。

Lennart 认为，实现上来说，upstart 其实是在管理一个逻辑上的服务依赖树，但是这个服务依赖树在表现形式上比较简单，你只需要配置——“启动 B好了就启动A”或是“停止了A后就停止B”这样的规则。但是，Lennart 说，这种简单其实是有害的（this simplification is actually detrimental）。他认为，

• 从一个系统管理的角度出来，他一开始会设定好整个系统启动的服务依赖树，但是这个系统管理员要人肉的把这个本来就非常干净的服务依整树给翻译成计算机看的懂的 Event/Action 形式，而且 Event/Action 这种配置方式是运行时的，所以，你需要运行起来才知道是什么样的。

• Event逻辑从头到脚到处都是，这个事件扩大了运维的复杂度，还不如之前的 sysvint。 也就是说，当用户配置了 “启动 D-Bus 后请启动 NetworkManager”， 这个 upstart 可以干，但是反过来，如果，用户启动 NetworkManager，我们应该先去启动他的前置依赖 D-Bus，然而你还要配置相应的反向 Event。本来，我只需要配置一条依赖的，结果现在我要配置很多很多情况下的Event。

• 最后，upstart 里的 Event 的并不标准，很混乱，没有良好的定义。比如：既有，进程启动，运行，停止的事件，也有USB设备插入、可用、拔出的事件，还有文件系统设备being mounted、 mounted 和 umounted 的事件，还有AC电源线连接和断开的事件。你会发现，这进程启停的、USB的、文件系统的、电源线的事件，看上去长得很像， 但是没有被标准化抽像出来掉，因为绝大多数的事件都是三元组：start, condition, stop 。这种概念设计模型并没有在 upstart 中出现。因为 upstart 被设计为单一的事件，而忽略了逻辑依赖。

当然，如果 systemd 只是解决 upstart 的问题，他就改造 upstart 就好了，但是 Lennart 的野心不只是想干个这样的事，他想干的更多。

首先，systemd 清醒的认识到了 init 进程的首要目标是要让用户快速的进入可以操作OS的环境，所以，这个速度一定要快，越快越好，所以，systemd 的设计理念就是两条：

• To start less.
• And to start more in parallel.

也就是说，按需启动，能不启动就不启动，如果要启动，能并行启动就并行启动，包括你们之间有依赖，我也并行启动。按需启动还好理解，那么，有依赖关系的并行启动，它是怎么做到的？这里，systemd 借鉴了 MacOS 的 Launchd 的玩法（在Youtube上有一个分享——Launchd: One Program to Rule them All，在苹果的开源网站上也有相关的设计文档——About Daemons and Services）

要解决这些依赖性，systemd 需要解决好三种底层依赖—— Socket， D-Bus ，文件系统。

• Socket依赖。如果服务C依赖于服务S的socket，那么就要先启动S，然后再启动C，因为如果C启动时找不到S的Socket，那么C就会失败。systemd 可以帮你在S还没有启动好的时候，建立一个socket，用来接收所有的C的请求和数据，并缓存之，一旦S全部启动完成，把systemd替换好的这个缓存的数据和Socket描述符替换过去。

• D-Bus依赖。D-Bus 全称 Desktop Bus，是一个用来在进程间通信的服务。除了用于用户态进程和内核态进程通信，也用于用户态的进程之前。现在，很多的现在的服务进程都用 D-Bus 而不是Socket来通信。比如：NetworkManager 就是通过 D-Bus 和其它服务进程通讯的，也就是说，如果一个进程需要知道网络的状态，那么就必需要通过 D-Bus 通信。D-Bus 支持 “Bus Activation”的特性。也就是说，A要通过 D-Bus 服务和B通讯，但是B没有启动，那么 D-Bus 可以把B起来，在B启动的过程中，D-Bus 帮你缓存数据。systemd 可以帮你利用好这个特性来并行启动 A 和 B。

• 文件系统依赖。系统启动过程中，文件系统相关的活动是最耗时的，比如挂载文件系统，对文件系统进行磁盘检查（fsck），磁盘配额检查等都是非常耗时的操作。在等待这些工作完成的同时，系统处于空闲状态。那些想使用文件系统的服务似乎必须等待文件系统初始化完成才可以启动。systemd 参考了 autofs 的设计思路，使得依赖文件系统的服务和文件系统本身初始化两者可以并发工作。autofs 可以监测到某个文件系统挂载点真正被访问到的时候才触发挂载操作，这是通过内核 automounter 模块的支持而实现的。比如一个 open() 系统调用作用在某个文件系统上的时候，而这个文件系统尚未执行挂载，此时 open() 调用被内核挂起等待，等到挂载完成后，控制权返回给 open() 系统调用，并正常打开文件。这个过程和 autofs 是相似的。

下图来自 Lennart 的演讲里的一页PPT，展示了不同 init 系统的启动。

除此之外，systemd 还在启动时管理好了一些下面的事。

用C语言取代传统的脚本式的启动。前面说过，sysvint 用 /etc/rcX.d 下的各种脚本启动。然而这些脚本中需要使用 awk, sed, grep, find, xargs 等等这些操作系统的命令，这些命令需要生成进程，生成进程的开销很大，关键是生成完这些进程后，这个进程就干了点屁大的事就退了。换句话说就是，我操作系统干了那么多事为你拉个进程起来，结果你就把个字串转成小写就退了，把我操作系统当什么了？

在正常的一个 sysvinit 的脚本里，可能会有成百上千个这样的命令。所以，慢死。因此，systemd 全面用 C 语言全部取代了。一般来说，sysvinit 下，操作系统启动完成后，用 echo $$ 可以看到，pid 被分配到了上千的样子，而 systemd 的系统只是上百。

另外，systemd 是真正一个可以管住服务进程的——可以跟踪上服务进程所fork/exec出来的所有进程。

• 我们知道， 传统 Unix/Linux 的 Daemon 服务进程的最佳实践基本上是这个样子的 （具体过程可参看这篇文章“SysV Daemon”）——
  1. 进程启动时，关闭所有的打开的文件描述符（除了标准描述符0,1,2），然后重置所有的信号处理。
  2. 调用 fork() 创建子进程，在子进程中 setsid()，然后父进程退出（为了后台执行）
  3. 在子进程中，再调用一次 fork()，创建孙子进程，确定没有交互终端。然后子进程退出。
  4. 在孙子进程中，把标准输入标准输出标准错误都连到 /dev/null 上，还要创建 pid 文件，日志文件，处理相关信号 ……
  5. 最后才是真正开始提供服务。

• 在上面的这个过程中，服务进程除了两次 fork 外还会 fork 出很多很多的子进程（比如说一些Web服务进程，会根据用户的请求链接来 fork 子进程），这个进程树是相当难以管理的，因为，一旦父进程退出来了，子进程就会被挂到 PID 1下，所以，基本上来说，你无法通过服务进程自已给定的一个pid文件来找到所有的相关进程（这个对开发者的要求太高了），所以，在传统的方式下用脚本启停服务是相当相当的 Buggy 的，因为无法做对所有的服务生出来的子子孙孙做到监控。

• 为了解决这个问题，upstart 通过变态的 strace 来跟踪进程中的 fork() 和 exec() 或 exit() 等相关的系统调用。这种方法相当笨拙。 systemd 使用了一个非常有意思的玩法来 tracking 服务进程生出来的所有进程，那就是用 cgroup （我在 Docker 的基础技术“cgroup篇”中讲过这个东西）。cgroup主要是用来管理进程组资源配额的事，所以，无论服务如何启动新的子进程，所有的这些相关进程都会同属于一个 cgroup，所以，systemd 只需要简单的去遍历一下相应的 cgroup 的那个虚文件系统目录下的文件，就可以正确的找到所有的相关进程，并将他们一一停止。

另外，systemd 简化了整个 daemon 开发的过程：

• 不需要两次 fork()，只需要实现服务本身的主逻辑就可以了。
• 不需要 setsid()，systemd 会帮你干
• 不需要维护 pid文件，systemd 会帮处理。
• 不需要管理日志文件或是使用syslog，或是处理HUP的日志reload信号。把日志打到 stderr 上，systemd 帮你管理。
• 处理 SIGTERM 信号，这个信号就是正确退出当前服务，不要做其他的事。
• ……

除此之外，systemd 还能——

• 自动检测启动的服务间有没有环形依赖。
• 内建 autofs 自动挂载管理功能。
• 日志服务。systemd 改造了传统的 syslog 的问题，采用二进制格式保存日志，日志索引更快。
• 快照和恢复。对当前的系统运行的服务集合做快照，并可以恢复。
• ……

还有好多好多，他接管很多很多东西，于是就让很多人不爽了，因为他在干了很多本不属于 PID 1 的事。

Systemd 争论和八卦

于是 systemd 这个东西成了可能是有史以来口水战最多的一个开源软件了。systemd 饱受各种争议，最大的争议就是他破坏了 Unix 的设计哲学（相关的哲学可以读一下《Unix编程艺术》），干了一个大而全而且相当复杂的东西。当然，Lennart 并不同意这样的说法，他后来又写一篇blog “The Biggest Myths”来解释 systemd 并不是这样的，大家可以前往一读。

这个争议大到什么样子呢？2014 年，Debian Linux 因为想准备使用 systemd 来作为标准的 init 守护进程来替换 sysvinit 。而围绕这个事的争论达到了空前的热度，争论中充满着仇恨，systemd 的支持者和反对者都在互相辱骂，导致当时 Debian 阵营开始分裂。还有人给 Lennart 发了死亡威胁的邮件，用比特币雇凶买杀手，扬言要取他的性命，在Youbute上传了侮辱他的歌曲，在IRC和各种社交渠道上给他发下流和侮辱性的消息。这已经不是争议了，而是一种不折不扣的仇恨！

于是，Lennart 在 Google Plus 上发了贴子，批评整个 Linux 开源社区和 Linus 本人。他大意说，

这个社区太病态了，全是 ass holes，你们不停用各种手段在各种地方用不同的语言和方式来侮辱和漫骂我。我还是一个年轻人，我从来没有经历过这样的场面，但是今天我已经对这种场面很熟悉了。我有时候说话可能不准确，但是我不会像他样那样说出那样的话，我也没有被这些事影响，因为我脸皮够厚，所以，为什么我可以在如何大的反对声面前让 systemd 成功，但是，你们 Linux 社区太可怕了。你们里面的有精神病的人太多了。另外，对于Linus Torvalds，你是这个社区的 Role Model，但可惜你是一个 Bad Role Model，你在社区里的刻薄和侮辱性的言行，基本从一定程度上鼓励了其它人跟你一样，当然，并不只是你一个人的问题，而是在你周围聚集了一群和你一样的这样干的人。送你一句话—— A fish rots from the head down ！一条鱼是从头往下腐烂的……

这篇契文很长，喜欢八卦的同学可以前往一读。感受一下 Lennart 当时的心态（我觉得能算上是非常平稳了）。

Linus也在被一媒体问起 systemd 这个事来（参看“Torvalds says he has no strong opinions on systemd”），Linus在采访里说，

我对 systemd 和 Lennart 的贴子没有什么强烈的想法。虽然，传统的 Unix 设计哲学—— “Do one thing and Do it well”，很不错，而且我们大多数人也实践了这么多年，但是这并不代表所有的真实世界。在历史上，也不只有systemd 这么干过。但是，我个人还是 old-fashioned 的人，至少我喜欢文本式的日志，而不是二进制的日志。但是 systemd 没有必要一定要有这样的品味。哦，我说细节了……

今天，systemd 占据了几乎所有的主流的 Linux 发行版的默认配置，包括：Arch Linux、CentOS、CoreOS、Debian、Fedora、Megeia、OpenSUSE、RHEL、SUSE企业版和 Ubuntu。而且，对于 CentOS, CoreOS, Fedora, RHEL, SUSE这些发行版来说，不能没有 systemd。（Ubuntu 还有一个不错的wiki – Systemd for Upstart Users 阐述了如何在两者间切换）

其它

还记得在《缓存更新的套路》一文中，我说过，如果你要做好架构，首先你得把计算机体系结构以及很多老古董的基础技术吃透了。因为里面会有很多可以借鉴和相通的东西。那么，你是否从这篇文章里看到了一些有分布式架构相似的东西？

比如：从 sysvinit 到 upstart 再到 systemd，像不像是服务治理？Linux系统下的这些服务进程，是不是很像分布式架构中的微服务？还有那个D-Bus，是不是很像SOA里的ESB？而 init 系统是不是很像一个控制系统？甚至像一个服务编排（Service Orchestration）系统？

分布式系统中的服务之间也有很多依赖，所以，在启动一个架构的时候，如果我们可以做到像 systemd 那样并行启动的话，那么是不是就像是一个微服务的玩法了？

嗯，你会发现，技术上的很多东西是相通的，也是互相有对方的影子，所以，其实技术并不多。关键是我们学在了表面还是看到了本质。

延伸阅读

• Lennert 的博文：Rethinking PID 1
• Lennert 的演讲：systemd, beyond init （ PPT ）
• Wikipedia：Systemd
• LinuxVoice：Lennart Poettering 专访

（全文完）