【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
我的应用程序在Linux上作为后台进程运行。 它目前在终端窗口的命令行中启动。
最近一个用户正在执行该应用程序一段时间，它神秘地死了。 文本：
杀害
在终端上。 这发生了两次。 我问是否有人在不同的终端使用kill命令来杀死进程？ 没有。
在什么条件下Linux会决定杀死我的进程？ 我相信shell显示“已杀死”，因为该进程在收到kill（9）信号后死亡。 如果Linux发送了kill信号，系统日志中是否会有消息说明它被杀的原因？
#1楼
用于限制资源的PAM模块完全导致了您描述的结果：我的进程神秘地死于控制台窗口上的文本Killed 。 在syslog和kern.log中都没有日志输出。 顶级程序帮助我发现，在一分钟的CPU使用后，我的进程被杀死了。
#2楼
我最近遇到了这个问题。 最后，我发现我的进程在自动调用Opensuse zypper更新后被终止。 禁用zypper更新解决了我的问题。
#3楼
尝试：
dmesg -T| grep -E -i -B100 'killed process'
-B100表示杀戮发生前的行数。
在Mac OS上省略-T 。
#4楼
正如dwc和Adam Jaskiewicz所说，罪魁祸首可能是OOM杀手。 但是，接下来的问题是：如何防止这种情况发生？
有几种方法：
- 如果可以的话，为您的系统提供更多内存（如果是VM，则很容易）
- 确保OOM杀手选择不同的过程。
- 禁用OOM杀手
- 选择禁用OOM Killer附带的Linux发行版。
由于这篇文章 ，我发现（2）特别容易实现。
#5楼
像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()到探针。
来源：oschina
链接：https://my.oschina.net/u/3797416/blog/3154607