python - 如何使用python，bash和strace检测SIGHUP发送者

出于神秘的原因，构建我们的Hadoop集群的机器似乎经历了SIGHUP浪潮。所有机器都运行centos 6.7 / 8和Cloudera(CM + CDH)5.9。

当此类SIGHUP浪潮在一台机器上发生时，我看到进程卡住了(某些来自Hadoop，某些操作系统本地化，例如ntpd)，并且SIGHUP的痕迹记录在多个文件中。 / var / log / messages中的一个示例看起来像

Jan 30 10:19:43 hadoop21 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2451" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jan 30 10:19:43 hadoop21 ntpd[135740]: ntpd exiting on signal 1
Jan 30 10:19:43 hadoop21 init: tty (/dev/tty5) main process (134662) killed by HUP signal
...

为了进一步理解该问题，我决定尝试获取发送SIGHUP的进程的PID(我不确定这是否是我需要的最终信息，但是调查必须从某个地方开始)。

为了实现这一目标，我考虑了一个简单的Python脚本sighup_victim.py，并在其上附加了strace，并假设strace收集的最后一行将包含有趣的信息。我通过orchestrator.py进行编程，因此

orchestrator.py

import subprocess
p=subprocess.Popen(["python","sighup_victim.py"])
q=subprocess.Popen(["strace","-tt","-o","tracelog","-p",str(p.pid)])

如果我从终端运行orchestrator.py并手动触发信号，就像$kill -SIGHUP <p.pid>一样，我会在tracelog中得到它:

22:04:42.791561 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=69035, si_uid=0} ---
22:04:42.791910 +++ killed by SIGHUP +++

我认为这是成功的-strace确实可以报告已将SIGHUP发送给受害者和它的作者。

然后，我将orchestrator.py与对所有机器执行run_orchestrator.sh的脚本python orchestrator.py > /dev/null一起部署，并通过run_orchestrator.sh触发ssh。

到目前为止，在我看到SIGHUP波即将到来的4个场合中，有4个让sighup_victim.py快死了(如预期的那样)，但是tracelog中的最后一个条目是

22:11:46.145040 select(0, NULL, NULL, NULL, {60, 0} <detached ...>

好像strace进程总是在sighup_victim.py之前被杀死。对我来说，这种巧合只是说我没有完全理解这个问题。

我正在研究实现此想法的替代方法(特别是使用audit)，但是有人可以帮助我更好地了解正在发生的事情，以便我可以从我确实在做的错误中学到东西吗？

谢谢!
at Cloudera community forum提供(甚至更长的)问题描述。

最佳答案

/var/log/kern.log或dmesg中是否有任何内容？它会在一台机器上发生吗？

正如Rob所说的，SIGHUP与OOM内核杀死(例如SIGKILL)有很大不同。