syslogd의 메시지는 무엇을 의미하나요? 나는 무엇을 해야 합니까?

syslogd의 메시지는 무엇을 의미하나요? 나는 무엇을 해야 합니까?

최근 PuTTY를 통해 문제의 OpenSUSE 시스템에 연결했을 때 다음 메시지가 프롬프트에 직접 나타나기 시작했습니다.

Message from syslogd@host at Aug  5 11:04:03 ...
 kernel:[ 6177.851012] EIP: [<75c0234e>] 0x75c0234e SS:ESP 0068:f324dde1

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] Process sh (pid: 6245, ti=f2bee000 task=f32fd2b0 task.ti=f2bee000)

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] Stack:

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] Call Trace:

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] Inexact backtrace:

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020]

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] Code:  Bad EIP value.

Message from syslogd@host at Aug  5 11:15:01 ...
 kernel:[ 6836.654020] EIP: [<75c0234e>] 0x75c0234e SS:ESP 0068:f2befead

나는 Linux에 대해 매우 기본적인 몇 가지 사항을 알고 있지만 이것이 나를 당황하게 만들었습니다. 무슨 뜻이에요? 문제를 해결하려면 어떻게 해야 합니까?

편집하다결과적으로 시스템은 이제 실제로 액세스할 수 없으며 핑에 응답하는 동안 SSH를 사용할 수 없습니다. 기계에서 물리적 작업을 수행할 수 있습니까?

답변1

이 메시지는 커널에 다음이 있는 것처럼 보입니다.커널 패닉. 기본적으로 분해되어 있습니다. 시스템이 불안정해지거나 충돌하는 경우 할 수 있는 일이 많지 않습니다.

일반적으로 이러한 유형의 메시지는 콘솔에 표시됩니다. 거기에서 명령을 사용하여 dmesg -n 1인쇄를 억제할 수 있습니다. 양성인 경우에는 약간 짜증스러울 수 있기 때문입니다.

에서 발췌dmesg매뉴얼 페이지

-n level
       Set  the  level  at  which  logging  of messages is done to the 
       console.  For example, -n 1 prevents all messages, except panic
       messages, from appearing on the console.  All levels of messages
       are still written to /proc/kmsg,  so syslogd(8)  can  still be used 
       to control exactly where kernel messages appear.  When the -n option 
       is used, dmesg will not print or clear the kernel ring buffer.

EIP 값이 잘못되었습니다.

이 오류는 일반적으로 하드웨어(일반적으로 RAM)에 어떤 유형의 오류가 있음을 의미합니다. 나는 다음과 같은 것을 모집 할 것입니다기억력 테스트 86+RAM이 제대로 작동하는지 확인하십시오.

답변2

cgminer(vt_hoang)의 특정 분기를 실행할 때만 Raspberry Pi Zero에서 이것을 볼 수 있습니다. 일반적으로 약 2일 동안 실행되고 시스템이 충돌합니다. 동일한 cgminer는 다른 Pi에도 충돌을 일으킬 수 있습니다. 이전에는 메시지가 stderr로 전송되는 것을 알지 못했고, 재부팅 후에도 지속되도록 로깅을 설정하고 Journalctl 출력을 살펴보았습니다. valgrind와 gdb로 다시 시도해야 합니다.

그러나 오류 메시지에는 단순히 침묵을 적용해도 근본적인 문제가 해결되지 않는다는 내용만 나와 있습니다. 커널마다 다르게 동작할 수 있지만 실행 중인 일부 소프트웨어일 수도 있습니다. 이는 반드시 하드웨어 문제는 아닙니다.

관련 정보