web-dev-qa-db-ja.com

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経由で接続できないpingには応答します。マシン上で物理的にできることはありますか？

kernelopensusesyslog
6
pzkpfw

これらのメッセージは、カーネルに kernel panic があったようです。基本的にクラッシュしていました。システムが不安定/クラッシュしている場合にできることはほとんどありません。

通常、これらのタイプのメッセージはコンソールに表示されます。そこで、dmesg -n 1コマンドを使用して、それらが印刷されないようにすることができます。これは、それらが無害であるときに少し迷惑になる可能性があるためです。

dmesg man pageからの抜粋

-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）に何らかの障害が発生していることを意味します。 memtest86 + のようなものを入力して、RAMが正しく機能していることを確認します。

5
slm

特定のcgminerフォーク（vt_hoang）を実行している場合にのみ、Raspberry Pi Zeroで表示されます。通常、約2日間実行され、システムがクラッシュします。同じcgminerも別のPiをクラッシュさせます。以前にstderrへのメッセージに気づかなかったので、再起動後もログが永続的になるように設定し、journalctlの出力を確認しました。 valgrindとgdbでもう一度試す必要があります。

しかし、エラーメッセージはそれだけです。それらをシャットダウンしても、根本的な問題は修正されません。カーネルが異なると動作が異なる場合がありますが、実行中のソフトウェアである可能性もあります。これは必ずしもハードウェアの問題ではありません。

1
Alan Corey