前言
我们在平常强制停用一个进程的时候, 会选择什么命令? 一般在测试使, 不考虑程序突然中断带来的影响, 直接使用kill -9 pid强制停止就行.
但是, 就在刚刚, 我启动了一个docker容器, 进入容器后执行命令kill -9 1没有任何效果??? 啊这, 为什么呀?
尝试
为了解释这个现象, 我进行了一系列测试, 这里简单说一下, 具体过程就不细写了:
- 其他进程: 使用
kill -9杀掉pid不为1的进程, 是可以杀掉的 - 其他信号: 编写进程捕获其他信号(如
SIGTERM), 进程可以正常捕获
经过测试得出结论, pid为1的进程不会处理信号SIGKILL
解惑
那么为什么会这样呢? 我们知道, SIGKILL信号进程是不能捕获的, 只能执行操作系统规定的行为, 那么就有两个合理的猜测:
- 操作系统忽略了, 没有将信号发送给进程
- 进程收到了信号, 只是
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 进程恒为 true
handler == SIGDFL
判断信号的处理是否是默认的, 如果进程自己捕获了则为 false
!(force && sig_kernel_only(sig))
force: 同一个 pid namespace 发送信号时, 恒为0
sig_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. 具体可见这里
至此, 已经基本解决了之前的疑惑.
解决
-
在宿主机中执行
kill. 因为容器中的守护进程在宿主机中的pid并不为1 -
docker run --init. 启动容器的时候添加--init参数, 这样容器会启动一个守护进程来转发, 你运行的进程就不是守护进程啦.