dumb init对Docker有多重要？

我希望这个问题不会被标记为主要基于意见，而是有一个客观的答案

我已经阅读了，其中详细描述了为什么以及如何使用

dumbinit

。老实说，对于那些不太熟悉Linux进程结构工作原理的人来说，这听起来很有戏剧性——如果你不使用

dumbinit

，感觉你做的事情完全错了

这就是为什么我想在我自己的Docker图像中使用它…阻止我这样做的原因是我还没有找到一个正式的Docker图像使用它

• 举个例子：他们直接调用

  mongod

• 举个例子：他们直接调用

  postgres

• 举个例子：他们直接调用

  节点

如果

dumb init

非常重要，那么为什么显然没有人使用它？我在这里遗漏了什么？

如果您有一个生成新进程的进程，并且您没有实现好的信号处理程序来捕获子信号，并且在进程应该停止时停止子进程，则可以使用类似的或

如果您的流程没有产生新的流程（例如Node.js），那么这可能不是必需的

我猜MongoDB，PostgreSQL。。。可能运行子进程的子进程都实现了良好的信号处理程序。否则就会出现僵尸进程，有人提出了一个问题来解决这个问题

---

唯一的问题可能是官方语言图像，如node、ruby、golang。它们没有dumbinit/tini，因为您通常不需要它们。但这取决于可能实现错误的子执行代码的开发人员，他们要么修复信号处理程序，要么将helper用作PID 1。

（免责声明：我是Tini的维护者-Tini和dumb init都是容器的轻量级init系统）。请注意，一些Docker官方图片确实使用了这样的init系统：Redmine、Kibana、Mongo express、Sentry和Jenkins都是很好的例子。正如您所观察到的，这通常对成熟的应用程序而不是语言运行时更有用。@ThomasOrozco:您能从技术方面评论一下tini和dumb init之间的区别吗？只是了解了这两个，想知道tini的历史，dumb init是怎么搔痒的。从描述来看，他们似乎做了同样的事情（还没有比较源代码）。@hakre我相信dumb Int的人在编写Tini时并不知道，所以他们并没有发现Tini有什么根本性的错误，他们想用dumb Int来修复：）。两者之间有一些特性上的差异。例如，它们支持信号重写，而Tini不支持，但Tini支持subreapers，而它们不支持。不过，总的来说，如果你正在寻找僵尸收割，这两种方法都可以。@ThomasOrozco:谢谢你的解释。这对我来说是全新的，我仍然需要弄清楚僵尸收割是否有问题，因为我还没有找到如何激发它进行测试。Docker run现在有一个

--init

标志：

在容器内运行一个init，转发信号并收割进程。看起来这个实现是直接来自Tinition的，但这并不完全正确。例如，Bash脚本不能正确处理和发出信号。此外，Mongo/Postgres还依赖操作系统的init系统来处理僵尸和子进程的获取。这就是它的工作方式。此外，docker很快将拥有自己的init处理程序（现在合并到master中），但在您拥有支持此功能的版本之前，您应该始终拥有可以获取进程的PID1进程。请参阅：许多官方图片都引入了PID1流程。
gosu
README说它是
exec
s流程，这意味着该流程将成为PID1，因此这是正交的。根据设计，gosu所做的只是切换UID（顺便说一句，它在容器用例之外）。然而，拥有entrypoint.sh脚本意味着运行该脚本的shell是PID1，并且可以使用
trap
来传递信号，理论上可以使用
等待--any
来捕获僵尸，除非脚本以
exec
结尾，这在mongo的示例中就是如此。