是什么终止了我的进程以及为什么？

问题描述：

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

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

被剛剛

在终端上。这种情况发生了两次。我问是否有人在另一个终端上使用 kill 命令来终止该进程？没有。

在什么情况下 Linux 会决定终止我的进程？我认为 shell 显示“killed”是因为进程在收到 kill(9) 信号后终止。如果 Linux 发送了终止信号，系统日志中是否应该有一条消息解释终止的原因？

解决方案 1：

如果用户或系统管理员没有终止该程序，内核可能会终止该程序。内核只会在资源极度匮乏（例如内存+交换耗尽）等特殊情况下终止进程。

解决方案 2：

尝试：

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

其中-B100表示杀死发生之前的行数。

在 Mac OS 上省略-T。

解决方案 3：

这看起来是一篇关于这个主题的好文章：驯服 OOM 杀手（1）。

要点是 Linux会过度使用内存。当一个进程请求更多空间时，Linux 会将该空间提供给它，即使该空间已被另一个进程占用，前提是没有人真正使用它们请求的所有内存。当进程实际使用已分配的内存时，而不是请求时，它将独占该内存。这使得分配变得快速，并且可能允许您“作弊”并分配比实际拥有的更多的内存。但是，一旦进程开始使用这些内存，Linux 可能会意识到它在分配它没有的内存方面过于慷慨，并且必须终止一个进程以释放一些内存。要终止的进程基于一个分数，该分数考虑了运行时间（长时间运行的进程更安全）、内存使用情况（贪婪的进程不太安全）和其他一些因素，包括您可以调整的值，以降低进程被终止的可能性。文章中对此进行了更详细的描述。

编辑：这里有[[另一篇文章]](http://linux-mm.org/OOM_Killer) ( 2 )，很好地解释了如何选择进程（注释了一些内核代码示例）。这篇文章的妙处在于，它包含了一些关于各种规则背后原因badness()的评论。

解决方案 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

希望这对你有帮助。

一些典型的解决方案：

1. 增加内存（不是交换）

2. 查找程序中的内存泄漏并修复它们

3. 限制任何进程可以消耗的内存（例如，可以使用 JAVA_OPTS 限制 JVM 内存）

4. 查看日志和谷歌:)

解决方案 5：

这是 Linux内存不足管理器 (OOM)。您的进程之所以被选中，是因为“不良程度”——近期程度、驻留大小（正在使用的内存，而不仅仅是分配的内存）和其他因素的组合。

sudo journalctl -xb

您会看到如下消息：

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

解决方案 6：

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

有几种方法：

1. 如果可以的话，给你的系统提供更多的 RAM（如果是虚拟机的话很容易）

2. 确保 OOM 终止程序选择不同的进程。

3. 禁用 OOM Killer

4. 选择禁用 OOM Killer 的 Linux 发行版。

我发现（2）特别容易实现：

调整/proc/<PID>/oom_score_adj到-1000（自动将 调整oom_adj到-17和oom_score调整到0）。

请参阅如何在 Linux 中创建 OOM 排除以了解更多信息。

解决方案 7：

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

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

可以根据需要调整该脚本中的过滤if块，或将其删除以跟踪系统范围的信号流量。可以通过收集回溯来进一步隔离原因（分别在内核和用户空间的探测器中添加print_backtrace()和/或）。print_ubacktrace()

解决方案 8：

限制资源的 PAM 模块导致了您所描述的结果：我的进程神秘地死亡，控制台窗口上显示“Killed”文本。没有日志输出，无论是在syslog中还是在kern.log中。top程序帮助我发现，在 CPU 使用率达到一分钟后，我的进程就被杀死了。

解决方案 9：

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

在这种情况下，一个解决方案是找到具有更大资源的队列或在提交中定义更大的资源需求。

您可能还想查看man ulimit

尽管我不记得ulimit结果Killed我已经有一段时间不需要它了。

解决方案 10：

在我的例子中，这是发生在 Laravel 队列工作器上的。系统日志没有提到任何终止操作，因此我进一步查看，结果发现该工作器基本上是因作业超出内存限制（默认设置为 128M）而终止的。

运行队列工作者--timeout=600并--memory=1024为我解决了这个问题。

解决方案 11：

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

在每种情况下，OOMKiller 都只是判定进程使用了​​太多资源……机器甚至不会因为缺乏资源而出现故障。应用程序及其数据库都没有内存泄漏问题（或任何其他资源泄漏）。

我不是 Linux 专家，但我猜想它决定何时终止某些程序以及终止什么的算法很复杂。另外，有人告诉我（我不能保证其准确性）OOMKiller 嵌入到内核中，您不能简单地不运行它。

解决方案 12：

用户可以使用 kill 或 Control+C 来终止自己的程序，但我的印象是事实并非如此，而且用户向您抱怨了。

root 当然有能力杀死程序，但是如果有人在你的机器上拥有 root 权限并且正在杀死东西，那么你就会遇到更大的麻烦。

如果您不是系统管理员，系统管理员可能已经设置了 CPU、RAM 和磁盘使用配额，并自动终止超出配额的进程。

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

解决方案 13：

我最近遇到了这个问题。最后，我发现我的进程在 Opensuse zypper update 自动调用后就被杀死了。禁用 zypper update 解决了我的问题。