「コアダンプ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎systemd を使う: 情報を更新)
34行目: 34行目:
 
ProcessSizeMax=0}}
 
ProcessSizeMax=0}}
   
{{Note|{{ic|{{ic|[Coredump]}} セクション名を忘れずに含めてください。そうしないと、このオプションは無視されます。}}
+
{{Note|{{ic|[Coredump]}} セクション名を忘れずに含めてください。そうしないと、このオプションは無視されます。}}
   
 
それから systemd の設定をリロードしてください:
 
それから systemd の設定をリロードしてください:

2023年10月11日 (水) 21:44時点における版

コアダンプとは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、(デバッガなどによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、(systemd-coredump などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。

警告: コアダンプには機密データ(パスワードや暗号キーなど)が含まれている可能性があるため、信頼できる相手としか共有しないでください。

自動的なコアダンプの無効化

コアダンプの自動生成を無効化する理由としては以下のようなことが考えられます:

  • パフォーマンス: メモリの消費が激しいプロセスのコアダンプを生成するとき、システムリソースが浪費され、メモリの消去が遅延します。
  • ディスク容量: 圧縮されない場合、コアダンプはメモリの使用量と同じ分だけ、あるいはそれ以上のディスク容量を消費します。
  • セキュリティ: コアダンプは基本的に root しか読みことができないものですが、クラッシュの後にディスクに書き込まれた機密情報 (パスワードや暗号鍵など) が含まれている可能性があります。

sysctl を使う

sysctl を使って kernel.core_pattern を設定することでコアダンプを無効化できます。以下のファイルを作成してください:

/etc/sysctl.d/50-coredump.conf
kernel.core_pattern=/dev/null

設定を今すぐ適用するには、sysctl を使用してください:

# sysctl -p /etc/sysctl.d/50-coredump.conf

systemd を使う

systemd はデフォルトで全てのプロセスのコアダンプを /var/lib/systemd/coredump に生成します。/etc/systemd/coredump.conf.d/ ディレクトリに以下の内容で設定スニペットを作成することで生成しないようにすることが可能です。 (こちらを参照 coredump.conf(5) § DESCRIPTION, [1]):

/etc/systemd/coredump.conf.d/custom.conf
[Coredump]
Storage=none
ProcessSizeMax=0
ノート: [Coredump] セクション名を忘れずに含めてください。そうしないと、このオプションは無視されます。

それから systemd の設定をリロードしてください:

# systemctl daemon-reload

参照 systemd-coredump(8) § Disabling coredump processing

PAM limits を使う

PAM でログインしたユーザーの最大コアダンプサイズは limits.conf によって強制されます。これをゼロにすると、コアダンプが完全に無効になります。[2]

/etc/security/limits.conf
* hard core 0

ulimit を使う

コアダンプの上限容量は ulimit によって決まります。ulimit をゼロに設定すればコアダンプは完全に無効化されます [3]:

/etc/security/limits.conf
* hard core 0

コアダンプの作成

任意のプロセスでコアダンプを生成したい場合は、まず gdb パッケージをインストールしてください。そして実行しているプロセスの PID を確認してください。例えば pgrep を使って:

$ pgrep -f firefox
2071 firefox

確認されたプロセスにアタッチ:

$ gdb -p 2071

そして (gdb) プロンプトで以下を実行:

(gdb) generate-core-file
Saved corefile core.2071
(gdb) quit

上記の例では core.2071 という名前のコアダンプファイルが生成されています。

コアダンプの保存場所

sysctlkernel.core_pattern は自動的に生成されたコアダンプの保存場所を決定します:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

/usr/lib/sysctl.d/50-coredump.conf のデフォルト設定では、コアダンプはシステムログとして journald に全て送信されます。

ノート: 完全なディスク暗号化をしていない場合、上記したことはプログラムのメモリがディスクにそのまま書き出されるということを意味します。たとえスワップを暗号化していてもコアダンプから情報が漏洩してしまう可能性があります。

journal からコアダンプを取得する方法は coredumpctl(1) を見てください。

コアダンプの確認

存在するダンプは coredumpctl を使って確認します:

# coredumpctl list

ダンプは一意に識別する必要があります。PID や実行ファイルの名前、実行ファイルのパスや journalctl の述部で指定することができます (詳しくは coredumpctl(1)journalctl(1) を参照)。コアダンプの詳細を確認するには:

# coredumpctl info match

"Signal" 列を注視することでクラッシュの原因の解明に役立ちます。gdb を使ってバックトレースを確認してさらに細かい解析をすることも可能です:

# coredumpctl gdb match

gdb を起動したら、bt コマンドを使ってバックトレースを出力してください:

(gdb) bt

コアダンプファイルのクリーンアップ

/var/lib/systemd/coredump/ に保存されたコアダンプファイルは systemd-tmpfiles --clean によって自動的にクリーンアップされます。これは systemd-tmpfiles-clean.timer によって毎日実行されます。コアダンプは最低でも 3 日間持続するように設定されています。systemd-tmpfiles --cat-config を参照してください。

参照