「Segmentation faultが出た。どのコードが問題なのか特定できない」
本番サーバーでプロセスが異常終了したとき、ログだけでは原因を突き止めるのが難しい場面があります。そういうときに頼りになるのがコアダンプです。
この記事では、systemd-coredumpの仕組みとcoredumpctlコマンドを使ったコアダンプの取得・解析方法を解説します。gdbとの連携まで把握しておけば、プロセス異常終了の調査が格段に速くなります。
動作確認環境：RHEL 9.4 / Rocky Linux 9.4 / Ubuntu 24.04 LTS
この記事のポイント
・coredumpctl listでコアダンプの一覧と詳細を確認できる
・coredumpctl gdb [PID]でgdbを直接起動しクラッシュを解析できる
・/etc/systemd/coredump.confでコアダンプの保存先とサイズを制御する
・btコマンドとprintでスタックトレースとNULLポインタを特定できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
コアダンプとは何か
プロセスが異常終了（クラッシュ）したとき、OSはそのプロセスのメモリスナップショットをファイルに書き出します。これがコアダンプ（core dump）です。コアダンプには、クラッシュ瞬間の情報がまるごと保存されています。
・スタックトレース（どの関数呼び出しで死んだか）
・CPUレジスタの状態（プログラムカウンタ・スタックポインタ等）
・ヒープ・スタックのメモリ内容
・開いていたファイルディスクリプタの情報
よく見かけるクラッシュシグナルは次の2つです。
・SIGSEGV（Segmentation fault）：不正なメモリアクセスで発生。NULLポインタ参照やバッファオーバーフローが主な原因
・SIGABRT（Abort）：プロセス自身がabort()を呼んだ場合。アサーション失敗やglibcが検知したヒープ破壊などで発生
コアダンプがあれば、gdbで正確なスタックトレースを取得でき、原因特定が大幅に速くなります。コアダンプを使わずにクラッシュを調査しようとすると、ログに残った断片的な情報だけを頼りにするしかありません。本番運用では必ずコアダンプを取得できる設定にしておくことが鉄則です。
systemd-coredumpの仕組みと設定確認
かつてLinuxではulimitの設定でコアダンプファイルをディスクに直接書き出していましたが、現在の主流ディストリビューション（RHEL 9/Rocky Linux 9/Ubuntu 22.04以降）ではsystemd-coredumpがコアダンプハンドラとして機能します。systemd-coredumpはクラッシュしたプロセスのコアをsystemdのジャーナルや/var/lib/systemd/coredump/以下に保存します。1. カーネルのcore_patternを確認する
systemd-coredumpが有効な環境では、core_patternが次のようになっています。# cat /proc/sys/kernel/core_pattern
|/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
【注意】core_patternが「|/lib/systemd/systemd-coredump」ではなく「core」や空欄になっている場合、systemd-coredumpが無効です。systemd-coredumpパッケージがインストールされているか確認してください。
2. /etc/systemd/coredump.confの設定を確認する
# cat /etc/systemd/coredump.conf
[Coredump] #Storage=external #Compress=yes #ProcessSizeMax=2G #ExternalSizeMax=2G #JournalSizeMax=767M #MaxUse= #KeepFree=
・Storage=external：コアダンプを /var/lib/systemd/coredump/ に保存（デフォルト）。「journal」にするとjournalに埋め込む形になるが、大容量のコアダンプには不向き
・Compress=yes：Zstdで圧縮保存。ディスクスペースを節約できる
・ProcessSizeMax：この値を超えるプロセスサイズのコアダンプは取得しない。デフォルトは2GB
設定変更後はsystemctl daemon-reloadを実行してください。変更内容は次回のコアダンプ発生時から適用されます。
3. コアダンプの保存先を確認する
# ls -lh /var/lib/systemd/coredump/
-rw-r----- 1 root systemd-coredump 3.2M Jul 20 14:35 core.myapp.1000.abc123.12345.1721123456000000.zst
coredumpctlでコアダンプを一覧・取得する方法
coredumpctlはsystemd-coredumpが管理するコアダンプを操作するためのコマンドです。一般ユーザーでも参照できますが、コアダンプのdumpにはsudo権限が必要な場合があります。1. コアダンプの一覧を表示する（list）
coredumpctl list
TIME PID UID GID SIG COREFILE EXE Fri 2026-07-20 14:35:12 JST 12345 1000 1000 SIGSEGV present /usr/local/bin/myapp Fri 2026-07-20 09:12:44 JST 9988 1000 1000 SIGABRT present /usr/bin/python3.11
coredumpctl list myapp
2. コアダンプの詳細情報を表示する（info）
PIDを指定して詳細情報を確認します。coredumpctl info 12345
PID: 12345 (myapp) UID: 1000 (user01) GID: 1000 (user01) Signal: 11 (SEGV) Timestamp: Fri 2026-07-20 14:35:12 JST Command Line: /usr/local/bin/myapp --config /etc/myapp/conf Executable: /usr/local/bin/myapp Storage: /var/lib/systemd/coredump/core.myapp.1000.abc123.12345.1721123456000000.zst
3. コアダンプファイルを取り出す（dump）
gdbや外部ツールで解析するためにコアダンプファイルを取り出したい場合は、dumpサブコマンドを使います。coredumpctl dump 12345 -o /tmp/myapp.core
4. gdbを直接起動する（coredumpctl gdb）
ファイルをdumpせずにgdbを起動できます。最も手軽な解析方法です。coredumpctl gdb 12345
Linux上級トレーニングの詳細を見る ＞＞
gdbを使ったコアダンプ解析の基本
coredumpctl gdbまたはgdbで直接コアダンプを開いたら、以下のコマンドで原因を調べます。1. スタックトレースを表示する（bt）
gdbを起動したらまず bt（backtrace）を実行します。(gdb) bt
#0 0x00007f8a12345678 in __strcmp_avx2 () from /lib64/libc.so.6 #1 0x0000000000401234 in validate_config (cfg=0x0) at config.c:87 #2 0x0000000000401567 in main (argc=1, argv=0x7fff12345678) at main.c:42
2. フレームを選択して変数を確認する（frame / print）
(gdb) frame 1 (gdb) print cfg $1 = (Config *) 0x0 (gdb) list
【注意】gdbでlistを実行してもソースが表示されない場合は、バイナリにデバッグシンボルが含まれていません。RHELはdebuginfo-installコマンド、UbuntuはAPTの-dbgsymパッケージでデバッグ情報を追加インストールできます。
3. レジスタ情報を確認する（info registers）
(gdb) info registers
コアダンプのトラブルシュート：発生パターンと調査の流れ
現場でよく見かけるパターンと、それに対応する調査手順です。パターン1：Segmentation fault（SIGSEGV）
原因の候補：NULLポインタ参照・配列の範囲外アクセス・解放済みメモリへのアクセス（use-after-free）調査手順：
・btでスタックトレースを取得し、クラッシュしたフレームを特定する
・frameでそのフレームに移動し、printでポインタ変数がNULLか不正アドレスかを確認する
・ソースコードの該当行を確認して根本原因を特定する
パターン2：Abort（SIGABRT）
原因の候補：assert()失敗・glibcが検知したヒープ破壊・C++の例外未キャッチ調査手順：
・btでどのassertが失敗したか確認する
・journalctl _PID=[PID]でクラッシュ直前のsystemdログを確認する
・ヒープ破壊が疑われる場合はValgrindでのメモリ検査も検討する
パターン3：COREFILEが「missing」になっている
coredumpctl listのCOREFILE列が「missing」の場合、コアダンプが保存されていません。次の点を確認してください。・ProcessSizeMaxを超えるプロセスサイズが原因の場合は /etc/systemd/coredump.conf の ProcessSizeMax を増やす
・/var/lib/systemd/coredump/ のディスク空き容量が不足していないか確認する
・Storage=noneになっていないか /etc/systemd/coredump.conf を確認する
調査の標準フロー
# ステップ1: コアダンプ一覧を確認 coredumpctl list # ステップ2: 対象クラッシュの詳細を確認 coredumpctl info [PID] # ステップ3: journalctlでクラッシュ前後のsystemdログを確認 journalctl _PID=[PID] # ステップ4: gdbでスタックトレース解析 coredumpctl gdb [PID]
本記事のまとめ
コアダンプとcoredumpctlを使ったプロセス異常終了の調査方法をまとめます。| やりたいこと | コマンド |
|---|---|
| コアダンプの一覧を確認する | coredumpctl list |
| 特定コアダンプの詳細情報を確認する | coredumpctl info [PID] |
| コアダンプファイルを取り出す | coredumpctl dump [PID] -o /tmp/core.file |
| gdbで直接コアダンプを開く | coredumpctl gdb [PID] |
| gdbでスタックトレースを表示する | bt（gdb内で実行） |
| gdbでフレームを選択する | frame [番号]（gdb内で実行） |
| gdbで変数の値を確認する | print [変数名]（gdb内で実行） |
| core_patternを確認する | cat /proc/sys/kernel/core_pattern |
Linux上級トレーニングの詳細を見る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：ハングしたLinuxサーバーをMagic SysRqキーで安全に再起動する方法・REISUBの手順とsysctl設定
- この記事の属するカテゴリ：Linuxトラブルシューティングへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます