我正在尝试找到服务器挂起的根本原因。
我发现一个进程崩溃了，进程 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的具体用途是什么。
我无法获得有关该过程的任何详细信息，因为服务器由于负载增加而挂起，我们不得不重新启动它。不过，我们修复了重启后的 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 的一些事情。