我有一个程序（C++），它以多线程方式处理 TCP 套接字。多线程处理非常密集，大约有 100 个线程（POSIX 线程）。
有时，不太确定什么时候，程序会被终止SIGTERM。经过一番谷歌搜索后，我发现系统发送不正常SIGTERM。我决定看看如果我忽略这个信号会发生什么。现在系统发送SIGKILL。我假设它会尝试使用SIGTERM，并且当应用程序没有终止时，系统会杀死它。
我尝试在 gdb 中运行它，但没有收到任何信号。
我已经在 valgrind 中运行它，没有信号。也没有 valgrind 错误。内存消耗很正常，看来我没有内存泄漏。退出时，它有 7Mb 堆正在使用中。
沒有任何可疑之处/var/log/messages, /var/log/syslogd。
系统是Debian 2.6.32-5。
基本上，问题是为什么系统可以将SIGTERM其发送SIGKILL到任意进程？我怎样才能在那一点停下来看看会发生什么（gdb 改变了行为）。
答案1
“系统”是一个非常模糊的术语。如果我们谈论内核，内核将永远不会发送 SIGTERM。当 OOM Killer 被调用时，它会发送 SIGKILL。
可能的情况是脚本或某些内容存在错误pkill或killall命令与您的流程不匹配。当您使用 启动命令时gdb，它的进程名称和参数不同，因此它看起来与pkill/不同killall。
答案2
获取 systemtap 脚本并监视信号传递。最简单的方法可能就足够了，例如：https://sourceware.org/systemtap/examples/lwtools/killsnoop-nd.stp
可以扩展到例如打印杀手的整个进程树。
更好的脚本不会监视系统调用，而是监视信号实际传递的位置。编写这样的脚本留给读者作为练习。