サーバーがハングした根本的な原因を見つけようとしています。
プロセス 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 つまたは両方のプロセスを継承しているため、dbus が必要になる可能性があります。
それから、別の疑問が私を悩ませています。実は、dbus の問題は、そのサーバーを最近再起動した後に始まり、数日後にサーバーがハングしました。これらすべてのプロセスを正常に実行するために dbus が必要な場合、再起動後の数日間はハングしたプロセスがなかったのはなぜでしょうか。
質問の残りの部分が広範すぎる場合は、dbus に関する実際の質問にのみ回答してください。
ありがとう！
編集2:
そしてこれも:なぜ dbus が必要なのでしょうか?dbus に関していくつか明確にしています。