用户可以使用kill或Control+C杀死自己的程序，但我的印象是这并没有发生，而且用户向您投诉了。

Root当然有杀死程序的能力，但如果有人在你的机器上安装了Root并杀死了一些东西，你就有更大的问题了。

如果您不是系统管理员，系统管理员可能对CPU、RAM、磁盘使用设置了配额，并且会自动杀死超过配额的进程。

除了这些猜测，没有更多关于这个项目的信息，我不能确定。

如果用户或系统管理员没有杀死内核可能已经杀死的程序。内核只会在特殊情况下终止进程，比如资源极度匮乏(比如mem+swap耗尽)。

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

在每种情况下，OOMKiller只是简单地认为进程使用了太多的资源……这台机器甚至还没有因为缺乏资源而崩溃。应用程序及其数据库都没有内存泄漏(或任何其他资源泄漏)问题。

我不是Linux专家，但我认为它的算法决定什么时候杀死什么东西是复杂的。此外，我被告知(我不能说这是准确的)，OOMKiller是烘焙到内核，你不能简单地不运行它。

这看起来是一篇关于这个主题的好文章:驯服OOM杀手(1)。

The gist is that Linux overcommits memory. When a process asks for more space, Linux will give it that space, even if it is claimed by another process, under the assumption that nobody actually uses all of the memory they ask for. The process will get exclusive use of the memory it has allocated when it actually uses it, not when it asks for it. This makes allocation quick, and might allow you to "cheat" and allocate more memory than you really have. However, once processes start using this memory, Linux might realize that it has been too generous in allocating memory it doesn't have, and will have to kill off a process to free some up. The process to be killed is based on a score taking into account runtime (long-running processes are safer), memory usage (greedy processes are less safe), and a few other factors, including a value you can adjust to make a process less likely to be killed. It's all described in the article in a lot more detail.

编辑:下面是[另一篇文章](2)，它很好地解释了如何选择进程(带有一些内核代码示例的注释)。它的优点在于，它包含了一些关于各种bad()规则背后原因的注释。

在lsf环境中(交互式或其他)，如果应用程序的内存利用率超过了队列上的管理员预先设定的阈值，或者提交给队列的资源请求，那么进程将被杀死，这样其他用户就不会成为潜在运行的受害者。当它这样做时，它并不总是发送电子邮件，这取决于它的设置方式。

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

你可能还想复习man ulimit

虽然我不记得导致了死亡，但我需要它已经有一段时间了。

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

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

Try:

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

其中-B100表示在kill发生之前的行数。

在Mac OS上省略-T。

正如dwc和Adam Jaskiewicz所说，罪魁祸首很可能是OOM杀手。然而，接下来的问题是:我如何预防这种情况?

有几种方法:

如果可以的话，给你的系统更多的内存(如果是虚拟机，这很简单) 确保OOM杀手选择不同的进程。 禁用OOM杀手 选择一个禁用OOM杀手的Linux发行版。

多亏了这篇文章，我发现(2)特别容易实现。

像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())。

这是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

让我先解释一下什么时候以及为什么调用OOMKiller ?

假设你有512内存+ 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内存) 查看日志和谷歌:)

在我的例子中，这发生在一个Laravel队列工作者身上。系统日志没有提到任何杀死，所以我进一步查看，结果发现工作人员基本上是在杀死自己，因为一个作业超出了内存限制(默认设置为128M)。

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