Question

我使用http://www.jejik.com/files/examples/daemon.py

中的模块进行python2.7守护进程

这个过程非常繁重，RAM使用率约为40 GB，子线程数为9。服务器使用RHEL 6.3，具有192 GB RAM和足够的CPU功率。

开始这个过程后，它会持续大约3-7个小时，然后被某人杀死，可能是内核。但我找不到dmesg和内核日志（我手动激活）的任何提示，没有那里。当没有作为守护进程启动时，我刚收到终端中的消息：“已杀死”。

已采取以下预防措施：

重置/ proc // oom_score_adj中的oom分数，以便在排序资源时oom杀手不会选择进程
将所有限制（可以增加）增加到最大值
将流程设置为nice / priority higher（prio -15）

在应用这些预防措施之前，这个问题已经存在，因此他们不对杀人负责

我还有一种机制来捕获所有异常，STDERR，STDOUT并将每个事件记录到一个旋转的日志文件中。但是在这个过程死亡之前没有任何有趣的东西。

该过程中使用的模块包括：oracle_cx，ibm_db，suds，wsgi_utils。但是当发生错误时，所有这些都会写日志。

任何人都知道如何追溯杀戮？谁和为什么？

提前谢谢

Answer 1

要查看该进程被终止时登录的用户，请使用命令last。

如果当时没有人登录，则该过程被某些信号杀死。

由于这是Python，找出杀死进程的最简单方法是为所有信号编写信号处理程序并记录它们。见here how to write a signal handler。请参阅this question how to catch them all。

如果获得核心转储，请连接具有足够空间的外部硬盘。或者使用ulimit将核心大小限制为1GB;这可能足以看出它崩溃的地方。

或者，使用gdb之类的调试器启动该过程;当“核心转储”信号被发送到流程时，它将确保您得到提示。

Answer 2

我认为我找到了根本原因，它可能是Python2.7中的一个错误在捕获所有可捕获信号并忽略它们之后，我可以跟踪更多错误消息并获得一些socket.error的提示。问题是，这样的错误将首先触发SIGTERM（trus尝试终止进程），然后写入STDERR。我捕获所有STDOUT和STDERR的机制可能会记录消息，因为主进程已被终止。无论如何，这是守护进程中的问题。这些是在流程终止之前的日志中的最后一行

2013-05-07 11:05:53,194 - STDERR - ERROR - Traceback (most recent call last):
2013-05-07 11:05:53,304 - STDERR - ERROR -   File "/var/lib/netcam_epd/lib/python2.7/SocketServer.py", line 582, in process_request_thread
2013-05-07 11:05:53,415 - STDERR - ERROR -     self.finish_request(request, client_address)
2013-05-07 11:05:53,489 - STDERR - ERROR -   File "/var/lib/netcam_epd/lib/python2.7/SocketServer.py", line 323, in finish_request
2013-05-07 11:05:53,587 - STDERR - ERROR -     self.RequestHandlerClass(request, client_address, self)
2013-05-07 11:05:53,684 - STDERR - ERROR -   File "/var/lib/netcam_epd/lib/python2.7/SocketServer.py", line 640, in __init__
2013-05-07 11:05:53,835 - STDERR - ERROR -     self.finish()
2013-05-07 11:05:53,887 - STDERR - ERROR -   File "/var/lib/netcam_epd/lib/python2.7/SocketServer.py", line 693, in finish
2013-05-07 11:05:54,084 - STDERR - ERROR -     self.wfile.flush()
2013-05-07 11:05:54,182 - STDERR - ERROR -   File "/var/lib/netcam_epd/lib/python2.7/socket.py", line 303, in flush
2013-05-07 11:05:54,326 - STDERR - ERROR -     self._sock.sendall(view[write_offset:write_offset+buffer_size])
2013-05-07 11:05:54,387 - STDERR - ERROR - error: [Errno 32] Broken pipe

显然，这是因为尝试写入一个不可写的套接字引起的。我认为库应该通过适当的返回值更好地处理这个问题，而不仅仅是抛出错误/异常，因为socket可以在正常运行中随时关闭。

我将验证这是否真的是根本原因。

杀死python守护进程（由内核？）

2 个答案: