Question

作为流程自动化例程的一部分，我有一个shell脚本，它通过CLI执行多个PHP脚本。其中一个，当然是最后一个，非常非常长。我交给的代码库是乱七八糟的，很多import.php脚本和ImportProduct.php对象基本上是不可修改的。

上周我完成了将代码更新到MySQLi并设置为测试并继续获得类似的进程终止消息。我已经挖掘了Magento PHP库，我自己的代码，原始代码，并且找不到任何会导致它的东西。仅凭这种格式就可以让人相信PHP CLI解释器，Linux操作系统或Apache（如果它甚至通过Apache运行，可悲的是不是非常精通系统管理员）导致终止。我通过SSH连接到远程服务器，但最后两行显示SSH本身没有超时。

通过PHP CLI的默认超时是没有，但将其设置为0或180天没有区别。因此，我认为问题处于较低水平。 请不要为根访问而烦恼，这不是我决定以这种方式工作的。

以下是我的消息部分。第5行包含终止消息。

new_import_products.php: ET068FII.TXT: Processed 406085 records in 1686 queries. 
import.php: Begin
ImportProduct.php> start 1055398
import.php: done loadFile()
./executeFullUpdateImport.sh: line 58: 4908 Killed php -f import.php
executeFullUpdateImport> full update/import completed
executeFullUpdateImport> Performed in 384m, 56s.\n\n
[root@stinedev import]# 
[root@stinedev import]# ls

搜索这样的东西是非常无益的。 Google返回了90亿页的关于如何杀死进程的内容......无论我使用哪种术语组合都不会保持活着（不可否认，我可能会提出错误的问题）。

Answer 1

我遇到过这种情况。一个可能的原因是oom杀手。这很容易检查。 dmsg将打印此行为。由于其他一些用户进程发送信号杀死，我的解决方案是使用内核试听。 google auditctl第一个条目。

Answer 2

这个问题的答案是它确实是一个内存不足（OOM）错误。希望消息在被杀时更具描述性。

日志文件取决于平台，但在CentOS上，它位于：

/var/log/messages[-date]

其中[-date]是可选的YYYYMMDD日期戳。有问题的条目看起来像这样：

... some log stuff here ...
Apr 13 21:26:23 MACHINE kernel: php invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Apr 13 21:26:23 MACHINE kernel: php cpuset=/ mems_allowed=0
Apr 13 21:26:23 MACHINE kernel: Pid: 1337, comm: php Not tainted 2.6.32-431.29.2.el6.x86_64 #1
Apr 13 21:26:23 MACHINE kernel: Call Trace:
... more log stuff here ...

其中MACHINE是您的装备的名称。

PS：感谢评论中的帮助。如果没有帮助，我无法回答这个问题，而是会选择他们的答案，但是不允许这样做。

什么是杀死这个过程以及如何阻止它这样做

2 个答案: