相关疑难解决方法(0)

我在docker容器中有一个入口点脚本,如下所示:

#!/bin/bash

echo starting up

function shut_down() {
    echo shutting down

    pid=$(ps -e | grep myapp | awk '{print $1}')
    kill -SIGTERM $pid  
    exit
}

trap "shut_down" SIGKILL SIGTERM SIGHUP SIGINT EXIT

/opt/myapp

我无法弄清楚如何通过docker stop在容器上运行来捕获发送的信号.以交互方式运行时,a ctrl+c将按预期触发它,但docker stop命令只等待10秒超时,并在不进入shut_down函数的情况下退出

如何捕获docker stopbash 发送的信号进行一些清理？

我读过这篇文章:https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

设置一些上下文:文章是关于容器中僵尸的问题,它试图说服我们这是一个真正的问题.

一般来说,我的感情很复杂.为什么这有关系 ？毕竟,即使万一在变装主机操作系统中的僵尸能够释放/杀死这个僵尸.我们知道容器中的进程是从主机操作系统正常进程的角度来看的(并且通常在容器中的进程是具有一些命名空间和cgroup的正常进程).

此外,我们还可以找到信息,以避免我们应该使用的僵尸问题bash -c ....为什么？也许,更好的选择是使用--init？

有人可以尝试解释这些事吗？

该--init标志的docker run原因tini初始化系统被用作ENTRYPOINT。结果，在容器中运行的应用程序将是init系统的子进程，因此它可以处理信号处理，僵尸收割等工作。

docker-compose也有一个init: true服务设置。

正如tini透明地工作一样，无需以任何方式修改Dockerfile（这就是tini文档所说的）。

所以我的问题是：

• 使用有什么缺点--init吗？
• 在哪种情况下最好避免使用--init？
• 如果没有严重的缺点：为什么--init没有默认设置？