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

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

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

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

这看起来是一篇关于这个主题的好文章:驯服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()规则背后原因的注释。

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

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