第2回「シリアルコンソールノススメ」


第1回では、カーネルパニックが発生した場合の情報取得方法として、 kdump を紹介しました。今回は、カーネルパニックまで至らない場合の情報取得方法として、シリアルコンソールを紹介します。

シリアルコンソールとは、カーネルが出力するメッセージを取得するための、比較的信頼できる方法です。
平常時であれば、カーネルが出力したメッセージは syslog デーモンによって /var/log/messages に保存されるようになっています。そのため、カーネルが出力したメッセージを確認したい場合、 /var/log/messages の内容を確認すれば済みます。

では、シリアルコンソールが役に立つのは、どのような場合なのでしょうか?それは、シリアルコンソールと syslog の動作方法の違いが意味を持つ場合です。 syslog デーモンは、カーネルが出力したメッセージを読み出して /var/log/messages へ書き出すという処理を行います。
この処理は非同期的に行われる(カーネルは syslog デーモンの処理が完了するのを待たない)ため、システムがハングアップしているなどにより syslog デーモンが動作できない状況に陥っている場合には、 syslog では対応できません。
それに対して、シリアルコンソールへの出力は同期的に行われる(カーネルはコンソールへの出力処理が完了するのを待つ)ため、 syslog デーモンが動作できない状況に陥っていても対応できるのです。特に、カーネルがメッセージを出力した直後に電源リセットなどが発生するというケースにも対応できるという点が大きいです。

シリアルコンソールを使用する上での注意点としては、以下の点が挙げられます。

  1. タイミング情報
  2. ログレベル
  3. 通信速度
  4. リダイレクト機能

1. タイミング情報

syslog デーモンによって /var/log/messages に保存されたメッセージにはタイムスタンプが付与されますが、カーネルによってコンソールに出力されたメッセージにはタイミング情報が付与されていないかもしれません。
メッセージがいつ出力されたかは、トラブルとの関連を判断する上で重要な手掛かりです。

RHEL 5 や RHEL 6 のデフォルト設定ではタイミング情報(起動してからの経過時間)は付与されませんが、 RHEL 6 の場合は /sys/module/printk/parameters/time に 1 を、 RHEL 5 の場合は /sys/module/printk/parameters/printk_time に 1 を指定することにより、メッセージの行頭にタイミング情報を付与できるようになります。
システムの起動時に指定すれば良いので、起動時に自動的に実行される /etc/rc.local で指定すれば良いでしょう。

なお、カーネルのコマンドラインから、 RHEL 6 の場合は printk.time=1 という指定を、 RHEL 5 の場合は time という指定を行うことによっても、同じ効果が得られます。しかし、起動時に行われるカーネルの初期化処理のタイミングによって、起動が失敗してしまう可能性がありますので、カーネルのコマンドラインで指定する方法は推奨しません。

2. ログレベル

カーネルが出力するメッセージにはログレベルという優先度指定が存在しており、
/proc/sys/kernel/printk の最初の値よりも高いログレベルを持つメッセージのみがコンソールへ出力されます。

しかし、カーネルのコマンドラインで quiet や rhgb という指定が行われていると、コンソールに出力されるログレベルの優先度が下げられてしまい、デバッグ情報のように障害解析に有用な情報を取得できなくなってしまいます。
そのため、全てのカーネルメッセージをコンソールに出力できるようにするために、カーネルのコマンドラインから quiet および rhgb という指定を削除しておくと良いでしょう。

3. 通信速度

コンソールへの出力は同期的に行われるため、コンソールとの通信速度が遅い場合、その分後続の処理が遅延してしまいます。
特に、システムがハングアップした場合に情報を取得するための Magic SysRq キー操作では、割り込みが禁止された状態で大量のメッセージを出力することになるため、割り込み処理が禁止されている状態が長時間続くことにより、例えば死活監視のタイムアウトやデバイスのI/Oエラーなどが発生する可能性が高くなってしまいます。

そのため、コンソールとの通信速度は、サポートされている通信速度の範囲内で、正しく通信できるかどうかを確認しながら、なるべく大きな値を設定することを推奨します。

4. リダイレクト機能

一部のハードウェアは、シリアルコンソールのリダイレクトをサポートしています。
強力な業務用サーバーでは、物理的な RS-232C ケーブルの代わりに TCP/IP ネットワーク経由でシリアルコンソールにアクセスする機能を提供していることが多いです。
サーバーのマニュアルを確認してください。また、 VMware や KVM などの仮想化環境の場合には、ホスト上のファイルとして保存する機能が提供されていることが多いです。

シリアルコンソール経由でのカーネルメッセージの取得は昔から使われている方法で、その有用性は現在でも変わりません。
しかし、ホストへのログインが許可されていない仮想化環境のゲストや、シリアルコンソールの有効化/無効化のために再起動することが困難なサーバーもあることでしょう。
そこで、次回は、シリアルコンソールを使えない場合の代替案である netconsole について紹介します。

(半田哲夫)

コーヒーブレーク「サポートセンターのカルテ」

サポートセンターでは、依頼ごとに ID を割り当て、情報を管理しています。
その内容は、サポートを行うために必要な情報(たとえばシステムの構成や使用しているプロダクトのバージョンなど)と依頼元に関する情報の組み合わせです。

サポートセンターにとって、過去の対応履歴は文字通り、宝の山です。
NTT OSS センタは 2006 年に設立されましたが、現在に至るまでの依頼と対応履歴が瞬時に確認できます。依頼に書かれているエラーメッセージについて、過去の問い合わせを検索するというような使い方の他に、その依頼元から過去にどのような依頼が来ているのか調べるということもよく行われます。
それはちょうど病院のお医者さんが、患者のカルテを確認するようなものです。過去の問い合わせ履歴から、システム(患者)の概要や、過去のトラブル(病気)、よく問題を起こす部分(弱点)を確認し、サポートセンターとのやりとりの記録から、依頼者の考え方や技術的スキルを参考にして対応します。
依頼してくる側は、発生した問題点で頭が一杯かもしれませんが、サポートセンターの中では、点ではなくて過去からつながった線として見て、対応を行っているのです。

頻度は高くありませんが、たまに過去に受けたのと同じ内容の依頼を受けることがあります。
そんなとき、サポートセンターの担当者は、「きっと忙しくて覚えていないんだろうな」と思いながら、過去の依頼履歴を参照、あるいは複写して回答します。過去の対応の中で、助言をしているときには、「助言したけど試してもらえなかったんだな。残念だな」と思いながら、再度同じ助言を繰り返します。
そんなふうにして作成されていると思って読み直すと、過去の回答の中に今まで見えていなかったものが見えてくるかもしれません。

(原田季栄)



第2回「シリアルコンソールノススメ」