第2回 PD思考法の基礎と情報収集（その2）：障害発生時の金科玉条（3/3 ページ）

[秋田英行（日本アイ・ビー・エム），オープンソースマガジン]

ログを読む

　ログを取ったらログを読む。これは至って当たり前である。ところが、なかなか的を射ない人がいるのも現状である。Linuxは何もしなくてもログを取っているため、デフォルト設定の範囲で必ずログを残している。そのため、問題が発生した際に、少なくともログを開いて「error」や「fail」などの記述がないか確認すれば見当を付けやすくなるにもかかわらず、悲しいかなそれすらも気付かない方がいるのも現実である。

　そこで、ここではdmesgとログファイル/var/log/messagesを用いて、ログにはどのような不具合を示すメッセージが残るかに焦点を当て、幾つかのサンプルを紹介していこう。

CD-ROMドライブの不具合

　まずはカーネルメッセージ関連のエラーについて、dmesgの例を見てみよう。

　リスト5は、CD-ROMドライブの不具合によるエラーメッセージの例である。この例では、「ATAPI device hda」の部分から、CD-ROMドライブに不具合があることが分かる。出力範囲が数行にわたるうえ、ステータスコードが16進のままであるため一見分かりづらいが、「Media load mechanism failed」というメッセージからメディアを読めない状態であることが分かる。

リスト5　CD-ROMドライブの不具合

NICに接続されたケーブルの不具合

　以下はよく目にするメッセージだが、「Link is Down」となっているため、eth1のNICに接続されたケーブルに不具合があることが分かる。

e100: eth1 NIC Link is Down

　リンクに関するメッセージからは、L2レベル*におけるネゴシエーション可／不可を確認できる。NICの「Link up」とは、ケーブルの接続先から信号の到達が可能という状態であるため、逆の「Link down」では信号の到達が不可能な状態を示している。

カーネル空間の不具合

　リスト6はカーネル空間で発生している不具合の例である。カーネル内の割り込み制御を行うdo_IRQ関数内でstack overflowが起きていることが分かる。

リスト6　カーネル空間での不具合

dhcpdのダウン

　今度は、/var/log/messagesに記録されたdhcpdに関するログを見てみよう（リスト7）。このログからは、設定ファイルの不備によってクライアントからのリクエストに応えられず、dhcpdがダウンしたことが分かる。

リスト7　dhcpdのダウン

時刻合わせの重要性

　さて、ログを読む上で重要なのが時刻合わせである。例えば、1システムだけを取ってみても、システム内にはハードウェアクロックとシステムクロックの2つが存在する。さらに、ハードウェアクロックにはRTC（Real Time Clock）*のほかに、管理プロセッサにも別途クロックが搭載されている場合がある。システムクロックはRTCを参照しているため、この2者でずれが生じることは少ないが、管理プロセッサは通常管理用として独立しているため、管理プロセッサのログとOSのログを付き合わせて確認するケースではずれが生じる可能性がある。この場合、時間差をどちらかのログで吸収する必要があり、時系列で調査するには注意が必要である。さらに、クライアント／サーバ間でPDを進めなければならない場合も同様のことが言える。このため、ハードウェアやOSの利用形態を理解した上で、事前に時刻同期を行う必要がある。

今回の締め

　以上でPDそのものやそのポイント、情報収集のやり方などをつかんでいただけただろうか。もちろんPDにおける必要事項はここに示したものだけではないが、問題が起きた際のPDへのキッカケをつかんでいただきたい。

　さて、今回はOS側からのアプローチによるPD手法を幾つか紹介したが、OS側からの視点だけでは進められない問題が発生する場合もある。そこで次回は、PDにおけるハードウェア側からのアプローチ方法を、管理プロセッサからの情報取得や、ハードウェアRAIDでのエラーを例に解説していく。

このページで出てきた専門用語

L2レベル

国際標準化機構（ISO）が制定したネットワーク階層構造モデルであるOSI参照モデルでの第2階層。物理的な通信経路を表す。

RTC（Real Time Clock）

マザーボードに搭載されている時計。OSは起動時にこの時計から時計情報を取得し、起動後は独自の時計（システムクロック）を参照する。

本記事は、オープンソースマガジン2005年12月号「Linux PD−問題判別脳力養成道場」を再構成したものです。