web-dev-qa-db-ja.com

カーネルパニックログはどこにありますか？

Handbrake/ffmpegに問題があります。約5分間のトランスコーディングの後、コンピューターがロックします。 caps-lockが点滅を開始するため、カーネルパニックであると確信しています。

何をすべきか、特定のバグについていくつかの論理的な質問がありますが、私は本当に一つのことを後にしています：すべてが死ぬ直前に何が起こったのですか？！

/var/log/kern.logを確認しましたが、その間に見られるのはDVDを貼り付けてから数分後にシステムが起動することだけです。エラーなし、パニック通知なし。

パニックを強制的に記録する方法はありますか？私はこれを再現できるとかなり確信しています（最近試した回数の100％が発生しました）。パニックの原因を見つけます。

kernellog
29
Oli

Ubuntuのシステムログはすべて rsyslog によって処理され、/etc/rsyslog.confおよび/etc/rsyslog.d/に設定が保持されます。

rsyslog の設定方法と可能なオプションの詳細については、 rsyslog.conf man page をご覧ください。

/etc/rsyslog.d/50-default.confを開くと、行の1つに以下が含まれていることがわかります。

*.*;auth,authpriv.none -/var/log/syslog*

この場合、探しているファイルはおそらくあなたが持つ巨大な/var/log/syslogログのいずれかであることを意味します。

ファイル名も-で始まることがわかります。これは、書き込み前にファイルがキャッシュされることを意味しますが、素晴らしいが、悪いログが残る可能性があります。 。ダッシュを削除して再起動するか、rsyslogをリ​​ロードしてからコンピューターを再度クラッシュさせます。/var/log/syslogを確認します。

20
Bruno Pereira

本当にカーネルパニックの場合、通常の方法ではログに書き込まれません。カーネルはこの時点でクラッシュしているため、ファイルシステムへの書き込みは危険な操作です-カーネルの多くはもはや信頼できないため、ログへの書き込みは実際にはブートローダー上にランダムながらくたを吐き出すかもしれません！

代わりに、メモリの内容をスワップにダンプし、後でデバッグできます。これは、カーネルクラッシュ/コアダンプとして知られています。

Ubuntu Wikiには、役に立つかもしれない CrashdumpRecipe があります-少し時代遅れに見えますが、あまり変更すべきではないと思います。

24
Caesium

シリアルポート

シリアルポートは、コンピューター間の単純な低レベル通信メカニズムです。

利点：

  • 簡単なセットアップ1回（ハードウェアがある場合）
  • データ送信は単純なワイヤとカー​​ネルAPIのみに依存するため、信頼性が高く、TCP/IPサブシステムなどよりもパニックの影響を受けにくい。

欠点：

  • 最新のラップトップのほとんどは、スペースを節約するためのシリアルポートをもう備えていません（露出？）。しかし、デスクトップと仮想マシンはまだあります。
  • また、データを受信するためにシリアルポートを備えた2台目のコンピューターも必要ですが、これは基本的にRaspberry Piなどのすべての組み込み開発ボードの場合です。
  • 無制限のTCP/IPネットワークとは異なり、物理層シリアルケーブルの長さによって制限されます。ただし、これは、シリアルとTCP/IPの間でインターフェイスするデバイスで回避できます。しかし、2つの間で変換するデバイスがあります。

シリアルポートは次のようになります。

rPIでは、GPIOを介して利用できます。

次に、必要なハードウェアがある場合、2番目のコンピューターからメインコンピューターに以下を使用して接続します。

screen /dev/ttyS0 115200

これは実際にシェルを提供します。

次に、メインマシンで、パニックを起こす操作を開始します。

パニックが発生すると、パニックダンプは2番目のマシンにストリーミングされます。ターミナルを上にスクロールすると、すべてを確認できます。

その他の方法

上記のハードウェアの制限を克服する他の方法もありますが、より複雑で信頼性が低くなります。注目すべき方法：

  • netdump：TCP/IPでパニックをストリーミングします。破損していないTCP/IPサブシステムに依存します。
  • kdump： https://askubuntu.com/a/104793/52975 で言及されているlinux-crashdumpの基礎となるメカニズムのようです。何が間違っている可能性がありますか？！ :-)

この素晴らしい回答も参照してください： https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

ステップデバッグ

最終的に、パニック出力を取得するにはいくつかのカーネル機能が動作する必要があり、パニックによってカーネル機能が破損する可能性があります。

しかし、カーネルでGDBを使用できる場合、誰がパニックを必要としますか？あなたがその筋金入りの場合は、見てください：

すべての問題は、完全な可視性が得られると（そして十分な時間があると！）落ちます。

3
Ciro Santilli 新疆改造中心996ICU六四事件