気付いたら、とあるFlatpakアプリケーションが起動しなくなっていた。コマンドから起動すると、segmentation faultによりコアダンプを出力していた。
Windowsの場合、コアダンプさえあればWinDbgで中身を確認することができる*1。Linuxの場合も、coredumpctl*2で同様のことは可能だが、特にgdb*3の場合、次の情報を特定する必要がある。
- コアダンプ
- 実行ファイル
- 共有ライブラリ
遭遇した障害を報告する際にも、これらの情報提供が要求されることが多い。この投稿では、これらの情報を特定するまでの一連の操作を紹介する。
ちなみに、この投稿での検証環境にはClear Linux*4を用いている。とはいえ、基本的にはどのLinuxディストリビューションでも共通に機能するはずだ。
事前確認
coredumpctl、あるいはgdbを操作する前に、次のコマンドを実行する。
ulimit -a cat /proc/sys/kernel/core_pattern ls -la /usr/lib/systemd/coredump-wrapper cat /usr/lib/systemd/coredump-wrapper
 |
 |
一連のコマンドで、次のことを確認している。
- 使用環境でコアダンプが出力されているか確認する。
- 「/proc/sys/kernel/core_pattern」を参照し、出力方法を確認する。
- 「coredump-wrapper」を調べると、シェルスクリプトであることが分かる。
- 「coredump-wrapper」の内容を調べる。
「ultimate -a」の、特に次の出力から、コアダンプが出力される環境が整っていることが分かる。
| core file size | unlimited |
| file size | unlimited |
「core_pattern」の記述から、「/usr/lib/systemd/coredump-wrapper」へパイプで引き渡されていることが分かる。
「coredump-wrapper」の内容を確認すると、最終的に「crashprobe」か「systemd-coredump」によってダンプ出力されていることが分かる。この投稿で使用している環境には「crashprobe」をインストールしていないため、「systemd-coredump」が使用されることになる。その出力を確認するには「coredumpctl」を使用する。
coredumpctl
まず「coredumpctl」を実行する。今回の障害はFlatpakアプリケーションに起因するので、「flatpak」に関連するダンプを確認する必要がある。
coredumpctl
coredumpctl list flatpak --since=2023-04-01
 |
 |
「coredumpctl」から問題のアプリケーション（実行ファイル）を指定することで、コアダンプを指定することなく「gdb」を起動できる。この時点で、障害の原因らしきところまで表示されていることが分かる。
coredumpctl debug flatpak
🔎「coredumpctl debug flatpak」の出力
ここからは「gdb」と操作は同じだ。バックトレースを確認し、共有ライブラリを特定する。
bt info share
 |
 |
ここまでに収集した情報を共有すれば、障害は解決するかもしれない。もし情報だけでなく、ファイルの提供を要求された場合、冒頭で触れた次のファイルを共有することになる。いずれも、これまでの情報の中でパスまで特定されている。
- コアダンプ
- 実行ファイル
- 共有ライブラリ
gdb
「coredumpctl」ではなく、直接「gdb」を用いる場合、まずコアダンプの出力先と、目的のダンプ・ファイルを特定する必要がある。
Clear Linuxの場合、ダンプファイルは「/var/lib/systemd/coredump/」にzstの圧縮ファイルとして格納されている。目的のファイルをフォルダ「~/work/debug/」へファイル「core」として展開する。
このファイルを実行ファイルとともに指定して「gdb」を実行すればよい。
ls -la /var/lib/systemd/coredump/ zstd -d /var/lib/systemd/coredump/目的のファイル.zst -o ~/work/debug/core gdb flatpak ~/work/debug/core
 |
 |
