CORE(5) Linux Programmer’s Manual CORE(5)
名前
core - コアダンプファイル
説明
あ る種のシグナルを受けた場合のデフォルトのアクションは、プロセスを終了
し (terminate)、 コアダンプファイル (core dump file) を生成することであ
る 。コアダンプファイルは、ディスク上に生成される終了時のプロセスのメモ
リイメージを内容とするファイルである。このイメージをデバッガ ( 例 え ば
gdb(1)) に読み込んで、プログラムが終了した時点のプログラムの状態を検査
することができる。どのシグナルを受けたときにプロセスがコアダンプを生 成
するかのリストは signal(7) に書かれている。
プロセスはソフト・リソース制限 RLIMIT_CORE を設定することで、「コアダン
プ」シグナルを受信した際に生成されるコアダンプファイルのサイズに上限 を
課すことができる。詳細は getrlimit(2) を参照。
コアダンプファイルが生成されない状況がいくつかある:
* プロセスがコアファイルを書き込む許可を持たない場合 (デフォルトでは、
コアファイルは core という名前で、カレント・ワーキング・ディレクトリ
に 生成される。命名規則の詳細は下記を参照)。コアファイルを生成しよう
としたディレクトリが書き込み可能でない場合、もしくは同じ名前のファイ
ルが存在し、そのファイルが書き込み可能でも通常のファイルでもない場合
(例えば、ディレクトリやシンボリックリンク)、コアファイルの生成は失敗
する。
* コアダンプに使おうとしたのと同じ名前の (書き込み可能な、通常の) ファ
イルがすでに存在し、そのファイルに対するハードリンクが 2個以上ある場
合。
* コアダンプファイルを生成しようとしたファイルシステムがフルであるか、
inode が全て使用されているか、読み込み専用でマウントされている場合。
ま た は、そのユーザのディスク使用量がそのファイルシステムのクオータ
(quota) に達している。
* コアダンプファイルを生成しようとしたディレクトリが存在しない場合。
* プロセス毎のリソース制限 RLIMIT_CORE (コアファイル の サ イ ズ) か
RLIMIT_FSIZE ( フ ァ イ ルサイズ) が 0 に設定されている場合。 getr-
limit(2) やシェルの ulimit コマンドのドキュメント (csh(1) の limit)
を参照。
* プロセスが実行したバイナリファイルの読み出し許可が有効になっていない
場合。
* プロセスが実行している set-user-ID (set-group-ID) プログラムの所有者
のユーザ (グループ) が、プロセスの実 UID (実 GID) と異なる場合 (但し
、 prctl(2) PR_SET_DUMPABLE 操 作 の 説 明 と 、 proc(5) の
/proc/sys/fs/suid_dumpable ファイルの説明も参照のこと)。
コアダンプファイルの名前
デ フォルトでは、コアダンプファイルの名前は core となるが、コアダンプフ
ァイルの名前を決めるのに使わ れ る テ ン プ レ ー ト を /proc/sys/ker-
nel/core_pattern ファイルに定義することで、ファイル名を変更することがで
きる (/proc/sys/kernel/core_pattern は Linux 2.6 および 2.4.21 以降で利
用できる)。テンプレートには % 指示子 (specifier) を入れることができる。
これはコアファイルが生成される際に、以下の値に置き換えられる。
%% 1 つの % 文字
%p ダンプされたプロセスのプロセスID (PID)
%u ダンプされたプロセスの実ユーザ ID (real UID)
%g ダンプされたプロセスの実グループ ID (real GID)
%s ダンプを引き起こしたシグナルの番号
%t ダンプ時刻 (紀元 (1970 年 1 月 1 日 0:00) からの秒数で表現さ れ
る)
%h ホスト名 (uname(2) で返される nodename と同じ)
%e 実行ファイル名 (パス名のプレフィックスは含まれない)
%c クラッシュしたプロセスのコアファイルのサイズに関するソフトリソ
ース上限 (Linux 2.6.24 以降)
テンプレートの末尾に 1 個だけ % がある場合、その % はコアファイル名には
含められない。また、上で列挙されていない % と文字の組み合わせがあった場
合も同様である。テンプレートにおける他の文字は、コアファイル名として そ
のまま使われる。テンプレートには '/' 文字を入れることができ、ディレクト
リ名の区切り文字と解釈される。結果として生成されるコアファイル名の最 大
サイズは 128 バイトである (2.6.19 より前のカーネルでは 64 バイト)。この
ファイルのデフォルト値は "core" である。以前のものとの互換性の た め 、
/proc/sys/kernel/core_pattern に "%p" が含まれず、かつ /proc/sys/ker-
nel/core_uses_pid (下記参照) が 0 でない場合は、.PID がコアファイル名に
追加される。
バ ージョン 2.4 以降の Linux ではコアダンプファイルの名前を制御する原始
的な方法も提供されている。 /proc/sys/kernel/core_uses_pid ファイルに 値
0 が書かれている場合、コアダンプファイルは単純に core という名前になる
。このファイルに 0 以外の値が書かれている場合、コアダンプフ ァ イ ル は
core.PID という形式の名前になり、ファイル名にプロセス ID が含まれる。
コアダンプのプログラムへのパイプ
カーネル 2.6.19 以降では、Linux は /proc/sys/kernel/core_pattern ファイ
ルの別の構文をサポートしている。このファイルの最初の文字がパイ プ 記 号
(|) であれば、その行の残りの部分は実行するプログラムとして解釈される。
コアダンプは、ディスク上のファイルに書き込まれるのではなく、プログラ ム
の標準入力として渡される。以下の点に注意すること。
* プログラムは絶対パス名 (もしくはルートディレクトリ / からの相対パス
名) で指定されなければならない。また、’|’ 文字の直後から始めなければ
ならない。
* プログラムを実行するために生成されるプロセスは、ユーザ、グループとも
root として実行される。
* コマンドライン引き数をプログラムに与えることができ (カーネル 2.6.24
以 降)、引き数はホワイトスペースで区切る (1行の最大長は 128 バイトが
上限である)。
* コマンドライン引き数には、上記のリストにある % 指示子を含めること が
で き る。例えば、ダンプされるプロセスの PID を渡すには、引き数に %p
を指定する。
どのマッピングをコアダンプに書き込むかを制御する
カーネル 2.6.23 以降では、Linux 固有のファイル /proc/PID/coredump_fil-
ter を使って、対応するプロセス ID を持つプロセスに対してコアダンプが行
われる際に、どのメモリセグメントをコアダンプファイルに書き込むかを制 御
できる。
こ のファイルの値はメモリマッピング種別 (mmap(2) 参照) のビットマスクで
ある。マスク内のあるビットがセットされると、そのビットに対応する種別 の
メ モリマッピングがダンプされる。セットされていないものはダンプされない
。このファイルの各ビットは以下の意味を持つ。
bit 0 無名のプライベートマッピング (anonymous private mappings) を
ダンプする。
bit 1 無名の共有マッピング (anonymous shared mappings) をダンプす
る。
bit 2 ファイルと関連付けられたプライベートマッピング (file-backed
private mappings) をダンプする。
bit 3 フ ァイルと関連付けられた共有マッピング (file-backed shared
mappings) をダンプする。
coredump_filter のデフォルト値は 0x3 である。この値は昔からの Linux の
挙 動 を反映したものであり、無名メモリセグメント (anonymous memory seg-
ments) だけがダンプされることを意味する。
coredump_filter の値に関わらず、フレームバッファな ど の memory-mapped
I/O に関するページは決してダンプされず、仮想 DSO ページは常にダンプされ
る。
fork(2) で作成される子プロセスは親プロセスの coredump_filter の値を継承
する。 execve(2) の前後で coredump_filter の値は保持される。
例のように、プログラムを実行する前に親シェルの coredump_filter を設定し
ておくと役立つことがある。
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
このファイルが提供されるのは、カーネルが設定オプション CONFIG_ELF_CORE
を有効にして作成された場合だけである。
備考
gdb(1) の gcore コマンドを使用すると、実行中のプロセスのコアダンプを取
得できる。
マルチスレッドプロセス (より正確には、 clone(2) の CLONE_VM で生成さ れ
た 別プロセスとメモリを共有しているプロセス) がコアダンプを生成する場合
、コアファイル名にプロセス ID が必ず付加される。ただし、 /proc/sys/ker-
nel/core_pattern の %p 指定によりコアファイル名のどこか他の場所にプロセ
ス ID がすでに含まれている場合は、プロセス ID が末尾に付加されない。 (
こ の機能がまず役に立つのは LinuxThreads 実装を利用している場合である。
LinuxThreads 実装では、プロセス内の個々のスレッドは異なるプロセス ID を
持つ。)
例
以下のプログラムは /proc/sys/kernel/core_pattern ファイルのパイプ構文の
使用例を示している。以下のシェルのセッションはこのプログラムの使用例 を
示 すものである (コンパイルして core_pattern_pipe_test という名前の実行
ファイルを作成している)。
$ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
$ su
Password:
# echo '|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s' > \
/proc/sys/kernel/core_pattern
# exit
$ sleep 100
^\ # type control-backslash
Quit (core dumped)
$ cat core.info
argc=5
argc[0]=
argc[1]=<20575>
argc[2]=
CORE(5) Linux Programmer’s Manual CORE(5)
NAME
core - core dump file
DESCRIPTION
The default action of certain signals is to cause a process to termi-
nate and produce a core dump file, a disk file containing an image of
the process’s memory at the time of termination. This image can be
used in a debugger (e.g., gdb(1)) to inspect the state of the program
at the time that it terminated. A list of the signals which cause a
process to dump core can be found in signal(7).
A process can set its soft RLIMIT_CORE resource limit to place an upper
limit on the size of the core dump file that will be produced if it
receives a "core dump" signal; see getrlimit(2) for details.
There are various circumstances in which a core dump file is not pro-
duced:
* The process does not have permission to write the core file. (By
default, the core file is called core or core.pid, where pid is the
ID of the process that dumped core, and is created in the current
working directory. See below for details on naming.) Writing the
core file will fail if the directory in which it is to be created is
nonwritable, or if a file with the same name exists and is not
writable or is not a regular file (e.g., it is a directory or a sym-
bolic link).
* A (writable, regular) file with the same name as would be used for
the core dump already exists, but there is more than one hard link
to that file.
* The filesystem where the core dump file would be created is full; or
has run out of inodes; or is mounted read-only; or the user has
reached their quota for the filesystem.
* The directory in which the core dump file is to be created does not
exist.
* The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)
resource limits for the process are set to zero; see getrlimit(2)
and the documentation of the shell’s ulimit command (limit in
csh(1)).
* The binary being executed by the process does not have read permis-
sion enabled.
* The process is executing a set-user-ID (set-group-ID) program that
is owned by a user (group) other than the real user (group) ID of
the process. (However, see the description of the prctl(2)
PR_SET_DUMPABLE operation, and the description of the
/proc/sys/fs/suid_dumpable file in proc(5).)
* (Since Linux 3.7) The kernel was configured without the CONFIG_CORE-
DUMP option.
In addition, a core dump may exclude part of the address space of the
process if the madvise(2) MADV_DONTDUMP flag was employed.
Naming of core dump files
By default, a core dump file is named core, but the /proc/sys/ker-
nel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define
a template that is used to name core dump files. The template can
contain % specifiers which are substituted by the following values when
a core file is created:
%% a single % character
%c core file size soft resource limit of crashing process (since
Linux 2.6.24)
%d dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE
(since Linux 3.7)
%e executable filename (without path prefix)
%E pathname of executable, with slashes ('/') replaced by exclama-
tion marks ('!') (since Linux 3.0).
%g (numeric) real GID of dumped process
%h hostname (same as nodename returned by uname(2))
%p PID of dumped process, as seen in the PID namespace in which
the process resides
%P PID of dumped process, as seen in the initial PID namespace
(since Linux 3.12)
%s number of signal causing dump
%t time of dump, expressed as seconds since the Epoch, 1970-01-01
00:00:00 +0000 (UTC)
%u (numeric) real UID of dumped process
A single % at the end of the template is dropped from the core file-
name, as is the combination of a % followed by any character other than
those listed above. All other characters in the template become a lit-
eral part of the core filename. The template may include '/' charac-
ters, which are interpreted as delimiters for directory names. The
maximum size of the resulting core filename is 128 bytes (64 bytes in
kernels before 2.6.19). The default value in this file is "core". For
backward compatibility, if /proc/sys/kernel/core_pattern does not
include "%p" and /proc/sys/kernel/core_uses_pid (see below) is nonzero,
then .PID will be appended to the core filename.
Since version 2.4, Linux has also provided a more primitive method of
controlling the name of the core dump file. If the /proc/sys/ker-
nel/core_uses_pid file contains the value 0, then a core dump file is
simply named core. If this file contains a nonzero value, then the
core dump file includes the process ID in a name of the form core.PID.
Since Linux 3.6, if /proc/sys/fs/suid_dumpable is set to 2 ("suid-
safe"), the pattern must be either an absolute pathname (starting with
a leading '/' character) or a pipe, as defined below.
Piping core dumps to a program
Since kernel 2.6.19, Linux supports an alternate syntax for the
/proc/sys/kernel/core_pattern file. If the first character of this
file is a pipe symbol (|), then the remainder of the line is inter-
preted as a program to be executed. Instead of being written to a disk
file, the core dump is given as standard input to the program. Note
the following points:
* The program must be specified using an absolute pathname (or a path-
name relative to the root directory, /), and must immediately follow
the ’|’ character.
* The process created to run the program runs as user and group root.
* Command-line arguments can be supplied to the program (since Linux
2.6.24), delimited by white space (up to a total line length of 128
bytes).
* The command-line arguments can include any of the % specifiers
listed above. For example, to pass the PID of the process that is
being dumped, specify %p in an argument.
Controlling which mappings are written to the core dump
Since kernel 2.6.23, the Linux-specific /proc/PID/coredump_filter file
can be used to control which memory segments are written to the core
dump file in the event that a core dump is performed for the process
with the corresponding process ID.
The value in the file is a bit mask of memory mapping types (see
mmap(2)). If a bit is set in the mask, then memory mappings of the
corresponding type are dumped; otherwise they are not dumped. The bits
in this file have the following meanings:
bit 0 Dump anonymous private mappings.
bit 1 Dump anonymous shared mappings.
bit 2 Dump file-backed private mappings.
bit 3 Dump file-backed shared mappings.
bit 4 (since Linux 2.6.24)
Dump ELF headers.
bit 5 (since Linux 2.6.28)
Dump private huge pages.
bit 6 (since Linux 2.6.28)
Dump shared huge pages.
By default, the following bits are set: 0, 1, 4 (if the CON-
FIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is
enabled), and 5. The value of this file is displayed in hexadecimal.
(The default value is thus displayed as 33.)
Memory-mapped I/O pages such as frame buffer are never dumped, and vir-
tual DSO pages are always dumped, regardless of the coredump_filter
value.
A child process created via fork(2) inherits its parent’s coredump_fil-
ter value; the coredump_filter value is preserved across an execve(2).
It can be useful to set coredump_filter in the parent shell before run-
ning a program, for example:
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
This file is provided only if the kernel was built with the CON-
FIG_ELF_CORE configuration option.
NOTES
The gdb(1) gcore command can be used to obtain a core dump of a running
process.
In Linux versions up to and including 2.6.27, if a multithreaded pro-
cess (or, more precisely, a process that shares its memory with another
process by being created with the CLONE_VM flag of clone(2)) dumps
core, then the process ID is always appended to the core filename,
unless the process ID was already included elsewhere in the filename
via a %p specification in /proc/sys/kernel/core_pattern. (This is pri-
marily useful when employing the obsolete LinuxThreads implementation,
where each thread of a process has a different PID.)
EXAMPLE
The program below can be used to demonstrate the use of the pipe syntax
in the /proc/sys/kernel/core_pattern file. The following shell session
demonstrates the use of this program (compiled to create an executable
named core_pattern_pipe_test):
$ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
$ su
Password:
# echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \
/proc/sys/kernel/core_pattern
# exit
$ sleep 100
^\ # type control-backslash
Quit (core dumped)
$ cat core.info
argc=5
argc[0]=
argc[1]=<20575>
argc[2]=
Copyright(C) linux-cmd.com All Rights Reserved. Author Takayuki Yukawa