Question

我的应用程序在Linux上作为后台进程运行。它目前在终端窗口的命令行中启动。

最近一位用户正在执行该应用程序一段时间，它神秘地死了。文字：

终止

在终端上。这发生了两次。我问是否有人在不同的终端使用kill命令来杀死进程？否。

在什么条件下Linux会决定杀死我的进程？我相信shell显示“已杀死”，因为该进程在收到kill（9）信号后死亡。如果Linux发送了kill信号，系统日志中是否会有消息说明它被杀的原因？

Answer 1

如果用户或系统管理员没有杀死内核可能拥有的程序。内核只会在特殊情况下终止进程，例如极端资源不足（想想mem + swap exhaustion）。

Answer 2

尝试：

dmesg -T| grep -E -i -B100 'killed process'

-B100表示杀戮发生前的行数。

在Mac OS上省略 -T 。

Answer 3

这看起来像是关于这个主题的好文章：Taming the OOM killer。

要点是Linux 过度使用内存。当一个进程要求更多空间时，Linux会给它那个空间，即使它被另一个进程声明，假设没有人真正使用他们要求的所有内存。该进程将独占使用它在实际使用时分配的内存，而不是在它要求时使用。这样可以快速进行分配，并且可能允许您“欺骗”并分配比实际更多的内存。但是，一旦进程开始使用这个内存，Linux可能会意识到它在分配它没有的内存时过于慷慨，并且必须杀死一个进程以释放一些内存。要杀死的过程基于考虑运行时的分数（长时间运行的过程更安全），内存使用（贪婪过程不太安全）以及一些其他因素，包括您可以调整以减少过程的值可能会被杀死。这一切都在文章中有更详细的描述。

编辑：这里是another article，它很好地解释了如何选择一个进程（用一些内核代码示例注释）。关于这一点的好处是它包含了对各种badness()规则背后的推理的一些评论。

Answer 4

我先解释一下OOMKiller被调用的时间和原因？

假设您有512 RAM + 1GB交换内存。所以从理论上讲，你的CPU可以访问总共1.5GB的虚拟内存。

现在，有一段时间内一切都在1.5GB的总内存中正常运行。但是，你的系统突然（或逐渐地）开始消耗越来越多的内存，并且达到了所用内存总量的95％左右。

现在说任何进程都要求内核提供大量内存。内核检查可用内存并发现它无法为进程分配更多内存。所以它会尝试释放一些内存调用/调用OOMKiller（http://linux-mm.org/OOM）。

OOMKiller有自己的算法来评估每个进程的排名。通常哪个进程使用更多内存成为被杀害的受害者。

我在哪里可以找到OOMKiller的日志？

通常位于/ var / log目录中。 /var/log/kern.log或/ var / log / dmesg

希望这会对你有所帮助。

一些典型的解决方案：

增加内存（不交换）
查找程序中的内存泄漏并修复它们
限制任何进程可以使用的内存（例如，可以使用JAVA_OPTS限制JVM内存）
查看日志和谷歌：）

Answer 5

这是Linux 内存不足管理器（OOM）。您的流程是由于“错误”而选择的 - 最近性，居住大小（正在使用的内存，而非刚刚分配）和其他因素的组合。

dwResult = WlanGetAvailableNetworkList(hClient,
                                                 &pIfInfo->InterfaceGuid,
                                                 0, 
                                                 NULL, 
                                                 &pBssList);

您会看到如下消息：

sudo journalctl -xb

Answer 6

正如dwc和Adam Jaskiewicz所说，罪魁祸首可能是OOM杀手。但是，接下来的问题是：如何防止这种情况发生？

有几种方法：

如果可以的话，为您的系统提供更多内存（如果是虚拟机，则很容易）
确保OOM杀手选择不同的过程。
禁用OOM杀手
选择禁用OOM Killer附带的Linux发行版。

由于this article，我发现（2）特别容易实现。

Answer 7

PAM module to limit resources导致了您描述的结果：我的进程神秘地死于控制台窗口上的文本 Killed 。 syslog 和 kern.log 中都没有日志输出。 top程序帮助我发现在CPU使用一分钟之后，我的进程被杀死了。

Answer 8

像systemtap（或跟踪器）这样的工具可以监控内核信号传输逻辑和报告。例如，https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

可以调整该脚本中的过滤if块以品味或消除以跟踪系统范围的信号流量。通过收集回溯可以进一步隔离原因（分别为内核和用户空间添加print_backtrace()和/或print_ubacktrace()到探针。

Answer 9

在lsf环境中（交互式或其他方式）如果应用程序超出某个预设阈值的内存利用率由队列上的管理员或提交到队列的资源请求，则进程将被终止，因此其他用户不会成为受害者潜在的逃跑。它并不总是在发送时发送电子邮件，具体取决于其设置方式。

在这种情况下，一种解决方案是找到资源较多的队列，或者在提交中定义更大的资源要求。

您可能还想查看man ulimit

虽然我不记得ulimit导致Killed因为我需要它已经有一段时间了。

Answer 10

我们在Linux下在客户站点（Red Hat，我认为）中遇到了反复出现的问题，OOMKiller（内存不足杀手）杀死了我们的主要应用程序（即服务器存在的原因）和它的数据库进程。

在每种情况下，OOMKiller只是决定这些流程正在使用大量资源......由于缺乏资源，机器甚至不会失败。应用程序及其数据库都没有内存泄漏问题（或任何其他资源泄漏）。

我不是Linux专家，但我宁愿收集它的算法来决定何时杀死某些东西以及杀死什么是复杂的。此外，我被告知（我不能说这个的准确性）OOMKiller被烘焙到内核中，你不能简单地不运行它。

Answer 11

在我的情况下，这是在Laravel队列工作者中发生的。系统日志中没有提到任何杀死，所以我进一步看了看，发现该工作者基本上是在杀死自己，因为作业超出了内存限制（默认设置为128M）。

使用--timeout=600和--memory=1024运行队列工作程序为我解决了这个问题。

Answer 12

用户可以使用kill或Control + C杀死他自己的程序，但我得到的印象不是发生了什么，并且用户向你抱怨。

root当然可以杀死程序，但是如果有人在你的计算机上有root并且杀了东西你会遇到更大的问题。

如果您不是系统管理员，系统管理员可能已经设置了CPU，RAM，磁盘使用率和自动杀死超过它们的进程的配额。

除了那些猜测之外，如果没有关于该计划的更多信息，我不确定。

Answer 13

我最近遇到了这个问题。最后，我发现我的进程在自动调用Opensuse zypper更新后被终止。禁用zypper更新解决了我的问题。

Answer 14

通过增加交换大小来解决此问题：

https://askubuntu.com/questions/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04

什么杀了我的过程，为什么？

14 个答案:

我先解释一下OOMKiller被调用的时间和原因？

我在哪里可以找到OOMKiller的日志？

一些典型的解决方案：