서버 정지의 근본 원인을 찾으려고 노력 중입니다.
프로세스 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가 프로세스 중 하나 또는 둘 다를 상속했을 수도 있으므로 dbus가 필요합니다.
그런 다음 또 다른 질문이 나를 괴롭히습니다. 실제로 해당 서버를 최근 다시 시작한 후 dbus 문제가 시작되었고 며칠 후에 서버가 중단되었습니다. 이러한 모든 프로세스를 성공적으로 실행하는 데 dbus가 필요한 경우 다시 시작한 후 며칠 동안 프로세스가 중단되지 않은 이유는 무엇입니까?
질문의 나머지 부분이 너무 광범위하다면 dbus에 관한 실제 질문에 대답해 보십시오.
감사합니다!
편집 2:
그리고 이것도:왜 dbus가 필요한가요?dbus에 관한 몇 가지 사항을 명확하게 설명합니다.