カーネルパニックは予期していない時に起こります。それが起こらないように備えることは誰にもできません。だから、「もし自分が管理しているシステムでそれが起こったらどうしよう」と考えてみることには意味があります。
カーネルパニックが起こったとき、あなたが気にするのは、「どうしてだろう？」、でありまた、「どうすれば元のように動作させられるだろう？」のはずです。２つ目の疑問は、多くの場合１つ目の疑問の結果に依存します。つまり、あなたは「どうしてカーネルパニックが発生したか」を調べることになります。それについて、（カーネルが正常に動作している今）できることを考えてみましょう。

カーネルパニックになるということは、「カーネルがパニックした」、すなわち「何が何だかよくわからない」状態になるということですから、それが発生してから論理的な処理はできません（できないからこそパニックしているわけです）。そこでできる最善は、後で原因を解析するために「おかしくなった状態を保存する」ことです。幸いなことに、Linuxカーネルは、そのための機能であるkdump を備えているので、管理者であるあなたはそれを設定しておけば良いわけです。

kdump を使用する上での注意点としては、以下の点が挙げられます。

1. カーネル初期化時
2. 予約メモリー容量
3. ディスク空き容量
4. 所要時間
5. 死活監視

1. カーネル初期化時

kdump の取得に失敗するという問い合わせの大部分は、 kdump 用カーネルがハードウェアの初期化処理を行う際にハングアップしてしまうというケースです。例えば、古いバージョンの VMware 製品には、 RHEL 6(Red Hat Enterprise Linux) ゲストの kdump 取得に失敗するという問題があります。また、ディストリビューターが提供している最新のカーネルを使用していない場合、最新のハードウェアに搭載されている BIOS/ ファームウェアでの動作テストが十分に行われていないという可能性が高くなります。ハードウェア初期化処理時に遭遇する問題はカーネル側に原因があるとは限らないので、事前に動作するかどうかを確認しておくのはもちろん、お使いのハードウェアの不具合情報も確認しておきましょう。

2. 予約メモリー容量

kdump 用カーネルが使用するメモリーは、平常時のカーネルが使用するためのメモリーの中から、crashkernel= というパラメーターを指定して割り当てます。この時、crashkernel=auto という指定をすることで、kdump 用カーネルが必要とするであろう量を自動的に見積もって割り当ててくれます。しかし、一部のデバイスドライバーは大量のメモリーを必要とするため、メモリー不足になってOOM killer が発動してkdump の取得に失敗するというケースがあります。十分な量が割り当てられているかどうかを確認しておきましょう。

3. ディスク空き容量

出力される kdump イメージファイルのサイズは搭載メモリーの量にもよりますが、ギガバイト単位になることもあります。ディスクの空き容量が不足した場合、kdump イメージファイルが不完全なものとなり、解析できません。 kdump の出力先としてディスクを指定する場合、ディスクの空き容量に注意しましょう。
また、カーネルパニックが発生したタイミングでマウントされていたパーティションは fsck によるエラー検査が必要な状態になっています。 kdump 用カーネルは自動的に fsck を実行しますが、そこで自動的には修復できないような問題が見つかると、 kdump の出力先として使用することができなくなってしまいます。もし可能なら、 kdump の出力先として、平常時のカーネルがマウントすることのない専用のパーティションを用意すると良いでしょう。

4. 所要時間

メモリー量が多いと kdump に要する時間が長くなります。ディスク使用領域の節約も兼ねて kdump イメージファイルを圧縮する機能も存在していますが、 kdump の仕組み上、 kdump 用のカーネルは 1CPU のみで動作するので、圧縮処理を複数 CPU の力も活用して高速化することができません。圧縮機能を使うべきかどうかを検討しておくと良いでしょう。

5. 死活監視

平常時のカーネルでは死活監視のためのプロセスが動作していて、ハードウェアの死活監視機能や、クラスタ構成された他のノードとの通信が行われているかと思います。しかし、 kdump 用カーネル上では kdump の取得を行うためのプロセスのみが動作していますので、そのような通信は行われません。そのため、 kdump 用カーネルの動作中に、タイムアウトによる強制的な電源リセットなどが行われてしまい、 kdump が失敗する可能性があります。 kdump 用カーネルの動作中にタイムアウトが発生しないように注意しましょう。

kdump の失敗原因を調査するには、コンソールに出力されるメッセージを取得することが有効です。もし可能なら、サポートに失敗原因の調査を依頼する際に添付できるように、シリアルコンソールを設定しておくと良いでしょう。

（半田哲夫）

コーヒーブレーク「サポートセンターへの依頼の書き方」

日々送られてくる依頼を見ていると、書き方は人によりそれぞれです。中には、サポートセンターの利用になれていないのか、書き方を迷った形跡が見受けられることもあります。そこで、今回は依頼の文章の書き方について説明しようと思います。

サポートセンターへの依頼は、サポートセンターのメンバーにとっては、自分達の仕事の定義、よりどころであり、もっとも重要な情報です。
依頼の内容は、案件を管理するシステムに登録され、案件が解決(クローズ)するまで、担当するメンバーに参照されますが、その読まれ方はメールなど通常の文章の読まれ方とは少し異なります。
具体的には、私たちは依頼の中から、サポートに必要な情報を抽出して読み取ります。
ここでサポートに必要な情報とは、問題の説明(トラブルや疑問の定義)であり、現在の状況であり、依頼の内容などです。それ以外の情報は、読み飛ばします、というか目に入りません。
毎日毎日、新たな依頼を読んでいると、この読み飛ばしがほとんど意識することなく行えるようになります。

そのような読まれ方をするということは、依頼の書き方は(実は)本質的に重要ではなく、必要なことが含まれていさえすれば良いことがわかります。
というと、「では必要なことは何か」と思われるかもしれませんね。残念ながら、それは状況により異なるので、一概には決まりません。それについては次のように考えてみてください。
あなたがサポートセンターに相談しようと思ったということは、あなたは何か困っていることか、確認したいことがあるはずです。だから、それが何かを自分に問いかけて、その結果を素直に文章にすれば良いのです。
わかっていることはわかっていることとして、わかっていないことはわかっていないままで大丈夫です。わかっていないこと(確認していないことの存在)はそれ自体情報であり、わかっていないことの中から確認すべきことを考えるのは、サポートセンターの仕事です。

(原田季栄)

• Hinemos関連サービス
• Hinemos