サーバー停止の根本原因を見つけようとします。
プロセス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
負荷を増やし、最終的にサーバーを停止する中断された14900のサブプロセスである可能性がある別のプロセス14939があります。
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
dbusは、プロセス間通信（IPC）に必要です（親プロセスまたは子プロセス呼び出しに関係なく、メッセージを送信するために他のプロセスと通信することを意味します）。
次のような言葉があります。
システム全体のデーモンとユーザー固有のデーモンは別々です。一般的なセッション内のIPCは、システム全体のメッセージバスプロセスを含まず、その逆も同様です。
それでは、ここでその逆の意味は何ですか？ IPCはセッションにdbusプロセス（システム全体またはユーザー）を要求しませんか？
これが正しい場合、14939と14900の間の通信にはセッション中なので、dbusはまったく必要ありませんか？それともそうではないかもしれません。 initは1つまたは2つのプロセスを継承するため、dbusが必要になる場合があります。
それから別の問題が私を悩ませました。実際、このサーバーを最近再起動した後、dbusの問題が始まり、数日後にサーバーがクラッシュしました。これらすべてのプロセスがdbusを正常に実行する必要がある場合、再起動後数日後にプロセスが中断されないのはなぜですか？
残りの質問が広すぎる場合は、dbusに関する実際の質問に答えてください。
ありがとうございます！
編集2：
これ：なぜdbusが必要なのですか？dbusに関するいくつかのことを明確に説明しました。