如何使用python、bash和s来检测SIGHUP发送器

Question

出于神秘的原因，构建Hadoop集群的机器似乎经历了SIGHUP的波动。所有设备都运行centos 6.7/8和Cloudera（CM+CDH）5.9。在

当这样的SIGHUP波出现在一台机器上时，我看到进程被卡住了（一些来自Hadoop，一些是操作系统本地的，比如ntpd），并且{}被记录在多个文件中。/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附加到它，前提是{}收集的最后一行将包含有趣的信息。我通过orchestrator.py以编程方式完成，因此

^{pr2}$

如果我从一个终端运行orchestrator.py并手动触发信号，如$kill -SIGHUP <p.pid>我在tracelog中得到这个：

^{3}$

我认为这是成功的--strace确实可以报告一个SIGHUP被发送给了受害者和作者。在

然后，我将orchestrator.py与一个脚本run_orchestrator.sh一起部署到所有计算机，并通过ssh触发run_orchestrator.sh。在

到目前为止，在我看到SIGHUP波来的4次中，我得到了sighup_victim.py死亡（如预期），但是{}中的最后一个条目是

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

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

我正在寻找实现这个想法的其他方法（特别是使用audit），但是有谁能帮我更好地了解发生了什么，这样我就可以从我犯下的错误中吸取教训吗？在

谢谢！
问题的描述（甚至更长）可用at Cloudera community forum。在

Answer 1

/var/log中有什么内容吗/内核.log或者dmesg？它发生在一台机器上吗？在

正如Rob所说，SIGHUP与OOM内核kill大不相同，比方说，这将是一个SIGKILL。在