第5回「 SysRq ノススメ」
Tweet
今回は、システムがデッドロックしたり無応答状態に陥ったりした場合に、システムの状態を取得するための Magic SysRq について紹介します。
Magic SysRq （以降 SysRq と略します）は他の手段での情報取得ができない状況でも使える有用な機能ですが、実際に活用するための難易度が高い情報取得方法ですので、事前に練習しておくことを推奨します。
SysRq を実行する上での注意点としては、以下の点が挙げられます。
- 取得するタイミング
- 出力されるログの量
- 割り込み禁止状態の影響
(1) 取得するタイミング
SysRq は、問題事象が発生している間に取得する必要があります。問題事象の解消後に取得しても、有用な情報は得られません。これは、 SysRq を使うためには、問題事象が発生している間に SysRq 要求を発行できるように備えておくことが必要であることを意味しています。
プロセスのスケジューリングが正常に機能している場合には、シェルのプロンプトから/proc/sysrq-trigger への書き込みを行うことにより SysRq 要求を発行することができるので、 ssh などを用いたリモートログイン中にも利用できます。しかし、シェルからの操作が不可能な状態に陥っている場合には、コンソールからキーボードのSysRq ボタンを操作することにより SysRq 要求を発行する必要がありますので、リモートログイン中には利用できません。
(2) 出力されるログの量
SysRq コマンドの内、全てのスレッドのバックトレースを取得するための SysRq-tコマンドが出力するカーネルメッセージの量は、動作中のスレッドの数に比例します。
syslog デーモンプロセスのスケジューリングが正常に機能していない状況ではカーネルメッセージが /var/log/messages に保存されることを期待できないため、シリアルコンソールや netconsole の設定も行っておくことを推奨します。
netconsole を使う場合、 SysRq コマンドによるメッセージを取得するために作成された udplogger が活躍することでしょう。
しかし、シリアルコンソールや netconsole を利用できない場合には、問題事象が解消するまでの間、 SysRq コマンドが出力したカーネルメッセージをメモリー上に保持しておけるようにするために、 log_buf_len= というカーネルコマンドラインパラメーターを使用してカーネルログバッファサイズを大きめに確保しておくことを推奨します。 x86_64 カーネルを使用している場合、例えばカーネルコマンドラインパラメーターに log_buf_len=16777216 という指定を行っておくことで、カーネルログバッファに16メガバイトを割り当てることができます。実際に出力されたカーネルメッセージの量は、十分な大きさのカーネルログバッファを確保している状態でSysRq コマンドを実行後に、 dmesg コマンドの出力を wc コマンドに渡すことで確認できます。想定される最大の負荷がかかっている状態で必要となるカーネルログバッファのサイズがどれくらいなのかを事前に確認しておくと良いでしょう。
(3) 割り込み禁止状態の影響
実行する SysRq コマンドの内容は状況により異なりますが、メモリーの使用状況を出力する SysRq-m コマンドと、全てのスレッドのバックトレースを取得する SysRq-tコマンドを、時間の経過に伴う状況の変化を確認するために複数回実行することが多いです。
SysRq-t コマンドを1回実行すると、割り込み処理が禁止されている状態が数秒から数分程度継続する場合があります。その結果、例えば死活監視のタイムアウトやデバイスのI／Oエラーなどが発生する可能性が高くなります。そのため、想定される最大の負荷がかかっている状態でどのような影響が出るのかを事前に確認しておくと良いでしょう。
（半田哲夫）
コーヒーブレーク「依頼は最初が肝心」
前回の記事のおさらいから始めます。あなたがサポートセンターに送った依頼は、サポート技術者にアサインされ、その技術者の検討が終了すると、その結果が依頼に対する回答して返却されます。早く結果を受け取るために、依頼者であるあなたが行うべきことは、
- サポート技術者のアサインが早く行われるように心がける
- サポート技術者が効率よく内容を検討できるように心がける
の2点です。ここで、「心がける」となっているのは、それらはサポートセンターの内部の処理であり、依頼する側では直接働きかけることができないためです。
技術者のアサインが早く行われるようにするためには、できるだけ早く依頼をすることです。しかし、ここでつまずくケースを多く見かけます。典型的な場合としては、
- 依頼内容がサポートセンターの対応範囲ではない（たとえば、OSSのサポートセンターに商用製品のことを質問する）
- 依頼の内容が文面から明確でない（ここで依頼の内容とは、「現在の状況」「（依頼側が認識している）問題の内容」「サポートセンターに頼みたい作業や欲しい結果」などの説明です）
- 必要な情報が不足している（必要な情報は依頼の内容により異なりますが、基本として対象となるソフトウェアのバージョン、使用しているパッケージで、再起動などの原因解析を依頼するのであれば、ログファイル等）
があります。こうした場合に何が起こるかというと、最初の場合には「申し訳ありませんが、サポート対象外なので、わかるところ（正しい相手）に依頼ください」というメッセージが送り返されて終了です。2つめと3つめについては、サポートセンター側から確認や情報提供を求められることになります。
個人と個人であれば「確認」は電話やメールで簡単に（短い時間で）行えます。しかし、サポートセンターとのやりとりは、そうはいきません。受け付けであれ、確認であれ、調査であれ、あなたの依頼に関する処理のすべては業務フローに基づきスケジュールされるので、サポートセンターとのやりとりは高い時間的コストを伴います。一往復ですまず二往復となると、問題解決に深刻な影響が生じます。
サポートセンターの「中の人」にとって、良い依頼と悪い依頼の違いは明確ですが、その情報（評価）は依頼元に返却されることはありません。サポートセンターから、依頼内容の確認や情報提供の依頼を受けたら、「ああ、失敗した。貴重な時間を失った」と思ってください。「良い依頼」とは要するに、サポート担当者がすぐに対応に着手できる依頼ということです。そうした依頼を受けると、「この人は、わかってるねぇ」とうれしくなります（それを伝えることはできませんけれども）。
（原田季栄）
Tweet