我正在嘗試找到伺服器掛起的根本原因。
我發現一個進程崩潰了，進程 ID 為 14900，以下是登入訊息。不保存核心轉儲，因為它與任何套件都不相關（ProcessUnpackaged=no）。
May 25 15:31:41 myserver abrt[15298]: Saved core dump of pid 14900 (/NFS_share/work_dir/freac/FREAC.Linux-2.6-x86_64-Release) to /var/spool/abrt/ccpp-2016-05-25-15:31:41-14900 (11644928 bytes)
May 25 15:31:52 myserver abrtd: Sending an email...
May 25 15:31:52 myserver abrtd: Email was sent to: root@localhost
May 25 15:31:52 myserver abrtd: Duplicate: UUID
May 25 15:31:52 myserver abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2016-05-17-10:25:46-48111
May 25 15:31:52 myserver abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2016-05-17-10:25:46-48111
May 25 15:31:52 myserver abrtd: Deleting problem directory ccpp-2016-05-25-15:31:06-12824 (dup of ccpp-2016-05-17-10:25:46-48111)
May 25 15:31:52 myserver abrtd: Failed to open connection to "system" message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
May 25 15:31:52 myserver abrtd: Directory 'ccpp-2016-05-25-15:31:41-14900' creation detected
May 25 15:31:52 myserver abrtd: Executable '/NFS_share/work_dir/freac/FREAC.Linux-2.6-x86_64-Release' doesn't belong to any package
May 25 15:31:52 myserver abrtd: 'post-create' on '/var/spool/abrt/ccpp-2016-05-25-15:31:41-14900' exited with 1
May 25 15:31:52 myserver abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2016-05-25-15:31:41-14900, deleting
還有另一個進程 14939，它可能是掛起的 14900 的子進程，這導致負載增加並最終掛起伺服器。
May 25 15:33:44 myserver ntpd[4430]: synchronized to 10.171.8.5, stratum 3
May 25 15:35:10 myserver kernel: INFO: task FREAC.Linux-2.6:14939 blocked for more than 120 seconds.
May 25 15:35:10 myserver kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 25 15:35:10 myserver kernel: FREAC.Linux-2 D 00000000ffffffff 0 14939 14658 0x10000084
May 25 15:35:10 myserver kernel: ffff8835d4ebd988 0000000000000046 ffff8835d4ebd908 ffffffffa0844e00
May 25 15:35:10 myserver kernel: ffff8828a4b61440 ffff881fedd4a540 ffff8835d4000001 ffffffff81129607
May 25 15:35:10 myserver kernel: ffff883f4c39baf8 ffff8835d4ebdfd8 000000000000fb88 ffff883f4c39baf8
May 25 15:35:10 myserver kernel: Call Trace:
當時dbus有問題，我們還沒有修復，但這可能是子進程14939失敗的原因。
我無法獲得有關該過程的任何詳細信息，因為伺服器由於負載增加而掛起，我們不得不重新啟動它。不過，我們修復了重啟後的 dbus 問題。
編輯1：
簡要查看此連結後的一些最新理解：https://dbus.freedesktop.org/doc/dbus-tutorial.html
進程間通訊 (IPC) 需要 dbus（意味著與另一個進程通訊以傳送訊息，與父進程或子進程呼叫無關）。
有一個說法：
系統範圍的守護程式和每位使用者守護程式是分開的。正常的會話內 IPC 不涉及系統範圍的訊息匯流排進程，反之亦然。
那麼，反之亦然在這裡意味著什麼 - IPC 是否在會話中不需要 dbus 進程（系統範圍或使用者）？
如果這是正確的，那麼 14939 和 14900 之間的通訊根本不需要 dbus，因為它們是在會話中？或者可能不是，可能是 init 繼承了一個或兩個進程，因此需要 dbus。
然後另一個問題困擾著我 - 實際上 dbus 問題是在該伺服器最近重新啟動後開始的，幾天后伺服器掛起。如果所有這些進程都需要 dbus 才能成功運行，為什麼重啟後幾天沒有任何進程掛起。
如果問題的其餘部分太廣泛，請嘗試回答有關 dbus 的實際問題。
謝謝你！
編輯2：
還有這個：為什麼需要 dbus？確實澄清了有關 dbus 的一些事情。