3

我有一个 python2.7 守护进程，使用来自http://www.jejik.com/files/examples/daemon.py的模块

该进程是一个繁重的进程，大约使用 40 GB RAM 和 9 个子线程。服务器使用 RHEL 6.3，具有 192 GB RAM 和足够的 CPU 能力。

启动该进程后，它会持续大约 3-7 小时，但随后被某人杀死，可能是内核。但是我在 dmesg 和内核日志（我手动激活）中找不到任何提示，那里什么都没有。当不作为守护进程启动时，我只是在终端中收到消息：“killed”。

已采取以下预防措施：

  • 重置 /proc//oom_score_adj 中的 oom 分数，以便 oom 杀手在对资源进行排序时不会选择进程
  • 将所有 rlimits（可以增加）增加到最大值
  • 将进程 nice/priority 设置得更高（prio -15）

这个问题在采取这些预防措施之前就已经存在，所以他们不对杀戮负责

我还有一种机制可以捕获所有异常、STDERR、STDOUT 并将所有内容记录到旋转的日志文件中。但就在这个过程结束之前，并没有什么有趣的事情发生。

进程中使用的模块包括：oracle_cx、ibm_db、suds、wsgi_utils。但是当发生错误时，他们都总是写日志。

有人知道怎么追查杀戮吗？谁和为什么？

先感谢您

4

2 回答 2

1

要查看进程被终止时谁登录了，请使用命令last。

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

由于这是 Python，找出是什么杀死了进程的最简单方法是为所有信号编写一个信号处理程序并记录它们。请参阅此处如何编写信号处理程序。看到这个问题如何抓住他们。

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

或者，使用调试器启动进程，例如gdb; 当“核心转储”信号发送到进程时，它将确保您得到提示。

于 2013-05-06T09:18:49.683 回答
0

我想我找到了根本原因，它可能是 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

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

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

于 2013-05-07T09:42:04.247 回答