Я пытаюсь найти основную причину зависания сервера.
Я обнаружил, что процесс с идентификатором процесса 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
dbus требуется для межпроцессного взаимодействия (IPC) (означает взаимодействие с другим процессом для отправки сообщений и не имеет ничего общего с родительскими или дочерними вызовами).
Есть такое заявление:
Системные и пользовательские демоны разделены. Обычный внутрисеансовый IPC не включает системный процесс шины сообщений и наоборот.
Итак, что здесь означает «наоборот» — требует ли IPC, не находящийся в сеансе, процесса dbus (общесистемного или пользовательского)?
Если это верно, то связь между 14939 и 14900 вообще не требует dbus, так как они находятся в сеансе? Или может и нет, может быть init унаследовал один или оба процесса и, следовательно, требуется dbus.
Тогда меня беспокоит другой вопрос - на самом деле проблема с dbus началась после недавнего перезапуска этого сервера, и через несколько дней сервер завис. Если dbus требуется для успешного выполнения всех этих процессов, почему не было ни одного зависшего процесса за эти несколько дней после перезапуска.
Пожалуйста, постарайтесь ответить на сам вопрос относительно dbus, если остальная часть вопроса слишком обширна.
Спасибо!
ПРАВКА 2:
И еще это:Зачем мне нужен dbus?проясняет некоторые вещи относительно dbus.