前言

我们在平常强制停用一个进程的时候, 会选择什么命令? 一般在测试使, 不考虑程序突然中断带来的影响, 直接使用kill -9 pid强制停止就行.

但是, 就在刚刚, 我启动了一个docker容器, 进入容器后执行命令kill -9 1没有任何效果??? 啊这, 为什么呀?

尝试

为了解释这个现象, 我进行了一系列测试, 这里简单说一下, 具体过程就不细写了:

• 其他进程: 使用kill -9杀掉pid不为1的进程, 是可以杀掉的
• 其他信号: 编写进程捕获其他信号(如SIGTERM), 进程可以正常捕获

经过测试得出结论, pid为1的进程不会处理信号SIGKILL

解惑

那么为什么会这样呢? 我们知道, SIGKILL信号进程是不能捕获的, 只能执行操作系统规定的行为, 那么就有两个合理的猜测:

1. 操作系统忽略了, 没有将信号发送给进程
2. 进程收到了信号, 只是pid=1的进程忽略了

那么究竟是怎么回事呢? 我找了些资料, 大概了解了此过程. 在man手册中也有介绍.

首先, pid=1是操作系统的守护进程, 其他所有的进程都是通过这个进程来启动的. 操作系统在发送信号时, 会进行是否忽略的判断, 这里以Linux 6.0为例, 判断的方法名称为sig_task_ignored, 对其进行简单分析:

static bool sig_task_ignored(struct task_struct *t, int sig, bool force)
{// .../*分析一下其中各个判断: unlikely(t->signal->flags & SIGNAL_UNKILLABLE)进程的 SIGNAL_UNKILLABLE 标志位是否为 true在每个 pid namespace 的 init 进程创建时, 都会标记此标志源码位置可见(我也没看懂...): https://github.com/torvalds/linux/blob/v6.0/kernel/fork.c#L2442结果: init 进程恒为 truehandler == SIGDFL判断信号的处理是否是默认的, 如果进程自己捕获了则为 false!(force && sig_kernel_only(sig))force: 同一个 pid namespace 发送信号时, 恒为0sig_kernel_only: 判断信号是否为 SIGSTOP 或 SIGKILL结果: 因此, 此条件恒为 true结果: 对于 init 进程来说, 第一个和第三个条件都恒为true, 因此是否忽略完全在于此信号进程是否进行了捕获*/if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) &&handler == SIG_DFL && !(force && sig_kernel_only(sig)))return true;// ...
}

因此, init进程, 若捕获了信号则能收到, 否则收不到. 而在所有的信号中(可通过 kill -l查看), SIGSTOP/SIGKILL这两个信号是不允许进程捕获的.

那么如何知道进程是否主动捕获了信号呢? 可以使用命令: cat proc/347/status | grep SigCgt, 将16进制转为2进制, 最右侧为1说明进程捕获了信号1. 具体可见这里

至此, 已经基本解决了之前的疑惑.

解决

1. 在宿主机中执行kill. 因为容器中的守护进程在宿主机中的pid并不为1

2. docker run --init. 启动容器的时候添加--init参数, 这样容器会启动一个守护进程来转发, 你运行的进程就不是守护进程啦.

   原文地址: https://hujingnb.com/archives/864