什麼殺了個人過程，爲何？

個人應用程序在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殺手。 可是，接下來的問題是：如何防止這種狀況發生？

有幾種方法：

1. 若是能夠的話，爲您的系統提供更多內存（若是是VM，則很容易）
2. 確保OOM殺手選擇不一樣的過程。
3. 禁用OOM殺手
4. 選擇禁用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()到探針。