现象：
- 你无法kill掉容器的1号进程，包括kill -11 kill -6 ，包括 kill -9，因为内核对于进程空间的1号进程是特殊对待的，不会安装默认信号处理程序。
- 如果你的进程是容器中的1号进程，那么在进程崩溃的时候，是不会有coredump文件产生的。
Hi folks,
I have looked into this issue and I want to share the results of my investigation, which turned out to be quite intriguing.The contained application has PID 1, which means that the Linux kernel treats it as a standalone init process for this namespace. The Linux kernel handles signals differently for the init process than it does for other processes. Signal handlers are not automatically registered for this process, meaning that signals will not take effect by default.
Since the contained application does not have user-defined signal handlers and the kernel does not register the default ones, the SIGABRT signal sent by the abort function is not handled at all.
In this situation, abort tries to kill the application by executing a forbidden asm instruction “HLT”. As a result, the CPU sets the GPF interruption and the kernel kills the contained application withSIGSEGV, which leads to the exit code 139. Docker just sets its exit code accordingly.The easiest way to make the contained application to have the default signal handlers is to run docker with the flag –init.
For an expanded explanation on how signals are handled in a docker container, I have provided a detailed answer with visual examples in my article.
Perhaps we should expand the description in https://github.com/docker/cli/blob/v20.10.2/docs/reference/run.md#foreground and/or link to that post. Currently it mentions;
Note
A process running as PID 1 inside a container is treated specially by Linux:
it ignores any signal with the default action. As a result, the process will
not terminate onSIGINTorSIGTERMunless it is coded to do so.Contributions welcome if someone is interested.
参考：
How signals are handled in a docker container | Dmitry Danilov (ddanilov.me)
Exit codes in docker when a program aborts | Dmitry Danilov (ddanilov.me)