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

最近,一个用户正在执行应用程序一段时间,它神秘地死亡了。文本:

杀了

在终端机上。这样发生了两次。我问是否有人在不同的终端使用kill命令杀死进程?不。

在什么情况下Linux会决定终止我的进程?我相信shell显示“已杀”是因为进程在接收到kill(9)信号后死亡。如果Linux发送了终止信号,系统日志中是否应该有一条消息解释为什么它被终止?


当前回答

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

其他回答

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

Try:

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

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

在Mac OS上省略-T。

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

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

有几种方法:

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

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

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