如何使用python、bash和strace检测SIGHUP发送方

Question

由于神秘的原因，构建Hadoop集群的机器似乎经历了一波又一波的SIGHUP。所有机器都运行centos6.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>中一样，我在跟踪日志中得到以下信息：

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一起部署到所有机器上，并通过ssh触发run_orchestrator.sh。

到目前为止，在我看到SIGHUP浪潮到来的4次情况中，有4次我得到了sighup_victim.py的死亡(正如预期的那样)，但tracelog中的最后一个条目是

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

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

我正在寻找实现这个想法的替代方法(特别是使用audit)，但是谁能帮助我更好地了解正在发生的事情，这样我就可以从我正在犯的错误中吸取教训？

谢谢!

问题的(甚至更长的)描述可以在at Cloudera community forum上找到。

Answer 1

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

正如Rob所说，SIGHUP与OOM内核终止有很大的不同，比如说，它将是SIGKILL。