Ubuntu Weekly Recipe

第674回 カーネルのクラッシュ情報を解析する

この記事を読むのに必要な時間:およそ 9.5 分

第673回のカーネルのクラッシュ情報を取得するでは,カーネルクラッシュ時に情報を収集する仕組みを有効化しました。得られた情報は活用しないと意味がありません。今回はその中身を解析する方法を紹介します。

デバッグパッケージのインストール

第673回では,意図的にシステムをクラッシュさせることで,dmesgとvmcoreを取得しました。カーネルが今際の際に次につながる情報を残してくれたのです。⁠しかしながらあのクラッシュが最後のpanicだとは思えない。もし,同じカーネルが続けて使われるとしたら,あのpanicの同類が,また世界のどこかへ現れてくるかもしれない……」

最初に行うべきなのは,前回紹介したように問題発生時のdmesgを読むことです。これである程度,状況の絞り込みは行えますし,運が良ければ原因がわかることもあります。しかしながら,dmesgだけだと「問題が起きた場所」はわかっても,⁠なぜそこで問題が起きたのか」まではわからないことも多いです。そこで利用できるのがクラッシュダンプです。これは現象発生したあと,実際にpanicが発生したタイミングでのカーネルメモリーの内容が保存されています。つまり,実行中のタスクは何かや,他のタスクの状態,各種変数の内容などを一通り確認できるのです。

というわけで第673回で取得した,クラッシュダンプの内容を精査しましょう。第673回ではsysrq-triggerを用いて意図的にクラッシュさせて,/var/crash/以下にdmesgとクラッシュダンプ(vmcoreファイル)を取得していました。今回解析するのはこのクラッシュダンプのほうです。解析にはcrashコマンドを利用します。crashはカーネルダンプの調査に特化した,gdbのラッパーツールです。

ただしカーネルをデバッガで調査するのであれば,vmlinuxやstripされていないカーネルモジュール群が必要です。実はこれらのファイルは非常にサイズが大きいため,通常のリポジトリには置かれていません。デバッグシンボル用のリポジトリを取り込む必要があります。まずは次のコマンドで,リポジトリを有効化してください。

$ sudo apt install ubuntu-dbgsym-keyring
$ sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)          main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates  main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted universe multiverse
EOF
$ sudo apt update

ちなみに上記はUbuntu 18.04 LTS以降でのみ有効です。18.04より前にはubuntu-dbgsym-keyringパッケージがないため,リポジトリにある鍵を別途取り込むようにしてください。また今回の手順はUbuntuのリリースカーネルにのみ有効です。Mainlineビルドや,その他サードパーティのカーネルの場合は,別の手段でデバッグシンボル付きカーネルを入手してください※1⁠。

※1
サイズの都合で,公式のMainlineビルドにおいてはデバッグパッケージは提供されていません。Mainlineビルドのクラッシュダンプを解析したいなら,まずは自分でカーネルを再ビルドするところからはじめましょう。

さて,今回は現在実行中のカーネルのデバッグパッケージをインストールしましょう。

$ sudo apt install linux-image-$(uname -r)-dbgsym

おそらく1GiBほどのサイズをダウンロードすることになるので注意してください。またクラッシュダンプ取得時のカーネルバージョンが,実行中のカーネルではない$(uname -r)の部分を適宜書き換えてください。クラッシュダンプのカーネルバージョンは,たとえばdmesgファイルの以下の部分で確認可能です。

[ 6262.530045] CPU: 3 PID: 111191 Comm: tee Kdump: loaded Tainted: G S       C  E     5.11.0-22-generic #23-Ubuntu

ここの5.11.0-22-generic$(uname -r)のそれに該当します。

ちなみにcrashコマンドとデバッグパッケージさえ用意できるなら,⁠クラッシュが発生したマシン」である必要はありません。運用中のサーバーはそのままクラッシュ情報収集したら,再度運用に戻して,別のマシンで解析することも可能です。

なお,別のアーキテクチャーの解析は,Ubuntuのcrashコマンドではできません。たとえば,Raspberry Piで発生したクラッシュダンプは,x86マシンでは解析できないのです。ただしこれはUbuntuのcrashコマンドのビルド方法に起因するものであり,crashコマンドを自前でクロスビルドするなら,別アーキテクチャーのダンプを解析することは可能です。

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member株式会社 創夢所属。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。