Linuxマシンが crash して停止してしまった、あるいは、再起動してしまった、ということはありませんか。
設定によっては、/var/crash 配下に、vmcore が取得できているかもしれません。
今回は、そんなコアファイルを読んでみたいと思います。
kernel-debuginfo, kernel-debuginfo-common パッケージをダウンロード、インストールします。
例えば、CentOS であれば、以下のサイトに行くと、ダウンロードできます。crash したマシンと同じバージョンのものをダウンロードしましょう。
vmcore を出力したカーネルと同じバージョンのkernel-debuginfo, kernel-debuginfo-common をインストールできたとして、以下の順番で確認します。
crash コマンドにより、vmcore を開きます。
$ crash /usr/lib/debug/lib/modules/<kernel-version>/vmlinux vmcore
例えば、以下に注目します。
KERNEL: /usr/lib/debug/lib/modules/<kernel_version>/vmlinux
DUMPFILE: vmcore [PARTIAL DUMP] ★<-- PARTIAL となっていますが、crash が効率性のために、0 で埋めた
ためで問題ないです。
CPUS: 8 ★<-- この数が64を超えるようであれば、spin lock で競合している可能性があります。
DATE: Sat Nov 5 06:58:00 2019 ★<-- 事象発生の日時となっています。
UPTIME: 17:23:57 ★<-- もし、数分であれば、boot プロセスで発生したと考えられ、再現する可能性があると
考えられます。209日ぐらいであれば、clock underflow 問題の可能性があります。
LOAD AVERAGE: 0.58, 0.44, 0.47 ★<-- （左から、1分、5分、15分）実行可能なプロセス数を示す。
左に向かって増加していれば、ロードが増加傾向で、事象発生が最近であることを示しています。
ロードが平板であれば、システムがスタックしていると考えられ、左に向かって減少していれば、
システムがアイドルになっているということになります。もし最近のロードが高ければ、ロードは、
実行可能なプロセスがCPUを得られないためなのか、I/O待ちまたは他のイベント待ちによる割り込み不可な
プロセスのためなのかを見分ける必要があります。
TASKS: 399 ★<-- この数が2000を超えるようであれば、リソースが足りないと言えます。
たとえ、CPU数が多くても、多くのTASKをさばけるわけではありません。
急上昇するようなら、リクエストの混雑をまねくだけのため。
NODENAME: xxxxxxxx
RELEASE: xxxx.el7.x86_64
VERSION: #1 SMP Sat Jun 18 01:51:33 ICT 2016
MACHINE: x86_64 (xxxx Mhz)
MEMORY: xxxx GB ★<--swap を含まないメモリサイズ。
PANIC: "BUG: unable to handle kernel NULL pointer dereference at (null)" ★<--panic string
問題を示す、panic string となっています。
PID: <数値>
COMMAND: "xxxx"
TASK: <アドレス> [THREAD_INFO: <アドレス>]
CPU: <CPU番号>
STATE: TASK_RUNNING (PANIC)
なんとなく分かってきましたね。
お腹すいたよー。。
つづきです。
https://qiita.com/intrajp/items/a66c7b142441fc19054d
参考:Linux カーネル Hacks オライリージャパン 第7章デバッグ
参考:「CRASHダンプ解析について 最終更新 2017/12/19」https://www.concurrent-rt.co.jp/external/TechSup/crash.html
参考:https://bitbucket.org/meszarv/webswing/issues/118/null-pointer-exception-when-running-inside
参考:https://access.redhat.com/solutions/969393