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

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

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

私はチェックしました/var/log/kern.log、そして、私が時間の周りに見るすべては私がDVDに固執することです、そして、数分後に、システムは起動します。エラーなし、パニック通知なし。

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

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

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

開く/etc/rsyslog.d/50-default.confと、次の行のいずれかが含まれていることがわかります

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

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

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

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

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

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

シリアルポート

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

利点：

• 簡単なセットアップ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の基盤となるメカニズムのようです。2 番目のLinuxカーネルを起動して、クラッシュしたカーネルを調べます。何が間違っている可能性がありますか？！:-)

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

ステップデバッグ

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

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

• QEMUまたは他のVM：https : //stackoverflow.com/a/42316607/895245
• JTAG

すべての問題が完全に可視化されると（そして十分な時間があると！）落ちます。