谁“杀了”我的过程，为什么？
我的应用程序在Linux上作为后台进程运行。 它目前在终端窗口的命令行中启动。
最近有一位用户正在执行该应用程序一段时间，它神秘地死了。 文本：
杀害
在终端上。 这发生了两次。 我问是否有人在不同的终端使用kill命令来终止进程？ 没有。
在什么情况下，Linux会决定杀死我的进程？ 我相信shell会显示“Killed”，因为进程在收到kill（9）信号后死亡。 如果Linux发送kill信号，应该在某个系统日志中有一条消息解释为什么它会被杀死？
如果用户或系统管理员没有杀死内核可能拥有的程序。 内核只会在极端资源匮乏（例如mem + swap耗尽）的特殊情况下杀死一个进程。
尝试：
dmesg -T| grep -E -i -B100 'killed process'
其中-B100表示杀死发生前的行数。
在Mac OS上省略-T 。
这看起来像是一篇关于这个主题的好文章：驯服OOM杀手。
要点是Linux 过度使用内存。 当一个进程要求更多空间时，Linux会给予它这个空间，即使它被另一个进程声称，但假设没有人真正使用他们要求的所有内存。 该进程将独占使用它在实际使用时分配的内存，而不是在请求时分配。 这使分配变得快速，并且可能会让你“欺骗”并分配更多的内存。 但是，一旦进程开始使用这种内存，Linux可能会意识到它在分配内存方面过于慷慨，并且不得不杀掉一个进程来释放一些内存。 被杀死的进程基于考虑到运行时间的分数（长期运行的进程更安全），内存使用率（贪婪进程不太安全）以及其他一些因素，包括可以调整以减少进程的值可能会被杀害。 这些都在文章中有更详细的描述。
编辑：这里是另一篇文章，很好地解释了如何选择一个过程（用一些内核代码示例注释）。 关于这一点的badness()在于它包含了对各种badness()规则背后的推理的一些评论。