谁“杀了”我的过程，为什么？
我的应用程序在Linux上作为后台进程运行。 它目前在terminal窗口的命令行中启动。
最近一个用户正在执行该应用程序一段时间，它神秘地死了。 文本：
杀害
在terminal上。 这发生了两次。 我问是否有人在不同的terminal使用kill命令来终止进程？ 没有。
在什么情况下，Linux会决定杀死我的进程？ 我相信shell会显示“Killed”，因为进程在收到kill（9）信号后死亡。 如果Linux发送kill信号，应该在某个系统日志中有一条消息解释为什么它被杀死了？
如果用户或系统pipe理员没有杀死内核可能拥有的程序。 内核只会在极端资源匮乏等特殊情况下（比如mem + swap耗尽）杀死一个进程。
这看起来像一个关于这个问题的好文章： 驯服OOM杀手 。
要点是Linux 过度使用内存。 当一个进程要求更多的空间时，Linux会给予这个空间，即使它被另一个进程所声称，但是假设没有人真正使用他们要求的全部内存。 进程将独占使用它在实际使用时分配的内存，而不是在请求时分配。 这使得分配变得快速，并且可能会让你“欺骗”并分配更多的内存。 但是，一旦进程开始使用这个内存，Linux可能会意识到分配内存太慷慨了，而不得不杀掉一个进程来释放一些内存。 被杀死的进程是基于考虑到运行时间（长时间运行的进程更安全），内存使用（贪婪进程不太安全）和一些其他因素（包括可以调整以减less进程的值）可能会被杀害。 这一切都在文章中更详细地描述。
编辑：这里是另一篇文章 ，很好地解释了如何select一个过程（用一些内核代码示例注释）。 关于这一点的badness()在于它包含了对各种badness()规则背后的推理的一些评论。
尝试：
dmesg | grep -E -i -B100 'killed process'
其中-B100表示击杀发生之前的行数。
让我先解释何时以及为什么OOMKiller被调用？
假设你有512个RAM + 1GB的交换内存。 所以理论上，你的CPU可以访问总共1.5GB的虚拟内存。
现在，一段时间内，一切都在1.5GB的内存中运行正常。 但是所有的突然（或逐渐）你的系统开始消耗越来越多的内存，并且达到了所使用内存总量的95％左右。
现在说任何进程已经从内核请求大量的内存。 内核检查可用的内存，发现它没有办法分配你的进程更多的内存。 所以它会尝试释放一些内存调用/调用OOMKiller（ http://linux-mm.org/OOM ）。
OOMKiller有自己的algorithm来评分每个进程的等级。 通常哪个进程使用更多的内存成为被杀害的受害者。
我在哪里可以findOOMKiller的日志？
通常在/ var / log目录中。 可以是/var/log/kern.log或/ var / log / dmesg
希望这会帮助你。
一些典型的scheme：
- 增加内存（不交换）
- find程序中的内存泄漏并修复它们
- 限制任何进程可以使用的内存（例如，可以使用JAVA_OPTS限制JVM内存）
- 查看日志和谷歌:)
正如dwc和Adam Jaskiewicz所说，罪魁祸首可能是OOM杀手。 然而，接下来的问题是：我如何防止这种情况？
有几种方法：
- 如果可以的话，给你的系统更多的RAM（如果它是一个虚拟机很容易）
- 确保OOM杀手select不同的过程。
- 禁用OOM杀手
- select一个随OOM Killer禁用的Linux发行版。
我发现（2）特别容易实现，感谢这篇文章 。
这是Linux 内存pipe理器（OOM） 。 您的stream程是由于“糟糕”而被选中的，这是“最近”，“常驻”大小（使用的存储空间，而不是刚分配的）以及其他因素的组合。
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
用于限制资源的PAM模块导致了您所描述的结果：我的进程在控制台窗口中死亡的文本中神秘死亡 。 没有日志输出，既不在syslog也不在kern.log 。 最重要的程序帮助我发现，在CPU使用一分钟后，我的进程被终止了。
像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块可以调整为尝试或消除以跟踪系统范围的信号stream量。 可以通过收集回溯来进一步隔离原因（分别为探针添加print_backtrace()和/或print_ubacktrace() ，对于kernel-和userspace-）。
在lsf环境中（交互式或其他方式），如果应用超出队列pipe理员超出某个预设阈值的内存利用率，或者将资源请求提交到队列，则进程将被终止，以便其他用户不会成为潜在的受害者逃跑。 它不会总是发送电子邮件，这取决于它的设置。
在这种情况下，一个解决scheme是find一个资源较大的队列，或者在提交中定义较大的资源需求。
你也可能想要复习一下man ulimit
虽然我不记得导致Killed的限制，因为我需要这个。
我们在客户端（Red Hat，我认为）在Linux下经常遇到问题，OOMKiller（内存不足的杀手）会杀死我们的主要应用程序（即服务器存在的原因）和数据库进程。
在每种情况下，OOMKiller只是简单地决定了这些stream程使用了很多资源……机器甚至不会因为资源不足而失败。 应用程序和它的数据库都没有内存泄漏（或任何其他资源泄漏）的问题。
我不是一个Linux专家，但我宁愿收集它的algorithm来决定什么时候杀什么，杀什么是复杂的。 另外，我被告知（我不能说这个的准确性），OOMKiller被烧入内核，你不能简单地不运行它。
用户有能力杀死自己的程序，使用杀或控制+ C，但我得到的印象是不是发生了什么，并且用户抱怨给你。
当然root有杀死程序的能力，但是如果有人在你的机器上有根，并且正在杀死你的东西，你就会遇到更大的问题。
如果您不是系统pipe理员，则系统pipe理员可能已经在CPU，内存，磁盘使用率以及超过它们的自动杀死进程中设置了配额。
除了这些猜测，我不确定没有关于该计划的更多信息。
我最近遇到这个问题。 最后，我发现我的进程在Opensuse zypper更新被自动调用后死亡。 禁用zypper更新解决了我的问题。
