ИМЯ

core - файла дампа памяти процесса

ОПИСАНИЕ

Для определённых сигналов действием по умолчанию является завершение процесса и
создание дампа памяти процесса — дискового файла, содержащего образ памяти
процесса на момент завершения. Этот образ может быть использован в отладчике
(например, gdb(1)) для исследования состояния программы на момент её завершения.
Список сигналов, которые приводят к созданию дампа памяти процесса, можно найти в
signal(7).

Процесс может установить свой программный предел ресурса RLIMIT_CORE в
максимальное значение по размеру файла дампа, который будет создан, если процесс
получит сигнал "дампа памяти"; подробней смотрите в getrlimit(2).

Есть несколько обстоятельств, при которых файл дампа памяти не создаётся:

* У процесса нет прав на запись файла дампа (по умолчанию файл дампа называется
core или core.pid, где pid — ID процесса из которого делается дамп, и создаётся
в текущем рабочем каталоге. Подробней об именовании смотрите далее). Запись
файла дампа завершится неудачно, если каталог, в котором он создаётся,
недоступен для записи, или если файл с таким же именем уже существует и
недоступен для записи или это необычный файл (например, это каталог или
символьная ссылка).

* Существует файл (обычный, доступный на запись) с именем, которое будет
использовано для дампа памяти, но есть более одной жёсткой ссылки на этот файл.

* Файловая система, где должен быть создан файл дампа, переполнена, закончились
иноды, она смонтирована только для чтения, достигнут предел пользовательской
квоты.

* Каталог, в котором должен быть создан файл дампа, не существует.

* Пределы ресурсов RLIMIT_CORE (размер файла дампа) или RLIMIT_FSIZE (размер
файла) для процесса установлены в ноль; смотрите getrlimit(2) и документацию на
команду оболочки ulimit (limit в csh(1)).

* Исполняемый процессом файл недоступен на чтение.

* Процесс выполняет программу с установленными битом set-user-ID (set-group-ID),
который принадлежит пользователю (группе) не совпадающей с ID реального
пользователя (группы) процесса или процесс выполняется программу, имеющую
файловые мандаты (смотрите capabilities(7)). Однако посмотрите описание
операции prctl(2) PR_SET_DUMPABLE, и описание файла /proc/sys/fs/suid_dumpable
в proc(5).

* Файл /proc/sys/kernel/core_pattern пуст и /proc/sys/kernel/core_uses_pid
содержит 0 (эти файлы описаны ниже). Заметим, что если
/proc/sys/kernel/core_pattern пуст и /proc/sys/kernel/core_uses_pid содержит 1,
то файлы дампа будет иметь имена в виде .pid, а такие файлы не показываются при
использовании ls(1) с параметром -a.

* (начиная с Linux 3.7) Ядро настроено без параметра CONFIG_COREDUMP.

Также, дамп память может не содержать часть адресного пространства процесса, если
в madvise(2) указан флаг MADV_DONTDUMP.
дампа:

%% одиночный символ %
%c программный предел размера файла дампа рухнувшего процесса (начиная с
Linux 2.6.24)
%d режим дампа — тоже, как значение возвращаемое prctl(2) с PR_GET_DUMPABLE
(начиная с Linux 3.7)
%e имя исполняемого файла (без пути)
%E путь к исполняемому файлу, в котором символы косой черты ('/') заменена на
восклицательные знаки ('!') (начиная с Linux 3.0).
%g (число) реальный GID процесса, с которого делается дамп
%h имя узла (как nodename, возвращаемое uname(2))
%i TID нити, из-за которой возник дамп, по отношению к пространству имён PID,
в котором располагается нить (начиная с Linux 3.18)
%I TID нити, из-за которой возник дамп, по отношению к начальному
пространству имён PID (начиная с Linux 3.18)
%p PID процесса, с которого делается дамп, так как он видится в пространстве
имён PID, котором расположен процесс
%P initial PID процесса, с которого делается дамп, так как он видится в
первоначальном пространстве имён PID, котором расположен процесс (начиная
с Linux 3.12)
%s номер сигнала, вызвавшего создание дампа
%t время дампа, выражается в секундах с начала эпохи, 1970-01-01 00:00:00
+0000 (UTC)
%u (число) реальный UID процесса, с которого делается дамп

Одиночный в конце шаблона отбрасывается от имени файла дампа вместе с символом
после %, отличным от перечисленных ранее. Все остальные символы в шаблоне
вставляются в имя файла дампа как есть. Шаблон может содержать символы '/',
которые интерпретируются как разделители для имён каталогов. Максимальный размер
получаемого имени файла дампа равен 128 байтам (64 байта для ядер до версии
2.6.19). Значение по умолчанию в этом файле равно "core". Для обратной
совместимости, если /proc/sys/kernel/core_pattern не содержит %p и значение в
/proc/sys/kernel/core_uses_pid (смотрите далее) не равно нулю, то к имени файла
дампа будет добавлен .PID.

Пути рассматриваются согласно активным настройкам для падающего процесса. Имеется
в виду пространство имён монтирования падающего процесса (смотрите
mount_namespaces(7)), его текущий рабочий каталог (находимый с помощью getcwd(2))
и его корневой каталог (смотрите chroot(2)).

Начиная с версии 2.4, Linux также предоставляет более примитивный метод управления
именем файла дампа памяти. Если файл /proc/sys/kernel/core_uses_pid содержит
значение 0, то файл дампа памяти просто называется core. Если в этом файле
содержится ненулевое значение, то к имени файла дампа добавится ID процесса (в
виде core.PID).

Начиная с Linux 3.6, если значение в /proc/sys/fs/suid_dumpable равно 2
(«suidsafe»), то шаблон должен быть или абсолютным путём (начинаться с символа
'/'), или каналом, как описано далее.

Передача дампов памяти в программу через канал
Начиная с версии 2.6.19, Linux поддерживает альтернативный синтаксис файла
/proc/sys/kernel/core_pattern. Если первым символом в этом файле будет символ
канала (|), то оставшаяся строка воспринимается как командная строка
пользовательской программы (или сценария), которую нужно запустить. Вместо записи
файла на диск дамп памяти передаётся в стандартный ввод программы. Отметим
* Создаваемый процесс для запуска программы будет выполняться с правами группы и
пользователя root.

* При выполнении с правами root не делается никаких исключений по обходу
безопасности. А именно, LSM (например, SELinux) работает как обычно и может не
дать обработчику доступ к информации упавшего процесса через /proc/[pid].

* Путь к программе рассматривается с учётом начального пространства имён
монтирования, так как она всегда выполняется в нём. На это не влияют настройки
(например, корневой каталог, пространство имён монтирования, текущий рабочий
каталог) падающего процесса.

* Процесс выполняется в начальных пространствах имён (PID, монтирования,
пользовательском и т. д.), а не в пространствах имён падающего процесса. Он
может использовать описатели, например %P, для нахождения правильного каталога
/proc/[pid] и, если нужно, протестировать/войти в пространства имён падающего
процесса.

* Процесс запускается с корневым каталогом, равным своему текущему рабочему
каталогу. Если нужно, то возможно изменить его на рабочий каталог выполняющего
дамп процесса воспользовавшись значением описателя %P для изменения
расположения выполняющего дамп процесса через /proc/[pid]/cwd.

* Программе можно передать аргументы командной строки (начиная с Linux 2.6.24),
отделяя их пробелами (максимальный размер строки 128 байт).

* Ограничение RLIMIT_CORE не применяется к файлам дампа, которые передаются по
каналу в программу через этот механизм.

/proc/sys/kernel/core_pipe_limit
При отправке дампов памяти через канал в программу пользовательского пространства
может быть полезным для собирающей программы получать данные о падающем процессе
из каталога процесса /proc/[pid]. Для безопасного выполнения ядро должно дождаться
завершения собирающей программы, и не удалять файлы падающего процесса
/proc/[pid]. Это, в свою очередь, создаёт возможность того, что неправильно
работающая собирающая программа может заблокировать очистку упавшего процесса
просто никогда не завершаясь.

Начиная с Linux 2.6.32, для защиты от этого можно использовать файл
/proc/sys/kernel/core_pipe_limit. Значением файла задаётся количество одновременно
падающих процессов, которые можно передавать через канал программе из пространства
пользователя параллельно. Если это значение превышено, то для выходящих за это
ограничение падающих процессов ядро пишет сообщение в лог, а дампы памяти не
передаёт.

Значение файла 0 является специальным. Оно означает, что параллельно можно
пересылать бесконечное количество процессов, но ожидание при это не происходит (т.
е., собирающей программе не гарантируется доступ к /proc/<crashing-PID>). Значение
по умолчанию для файла равно 0.

Управление отображениями, записываемыми в дамп памяти
Начиная с версии 2.6.23, в Linux появился файл /proc/[pid]/coredump_filter,
который определяет какие сегменты памяти записываются в файл дампа памяти при
отклике на событие создания дампа памяти процесса с соответствующим ID процесса.

Значение в файле является битовой маской типов отображений памяти (см. mmap(2)).
Если бит в маске установлен, то выполняется дамп отображения памяти
бит 5 (начиная с Linux 2.6.28)
Выполнять дамп частных огромных страниц.
бит 6 (начиная с Linux 2.6.28)
Выполнять дамп общих огромных страниц.
бит 7 (начиная с Linux 4.4)
Выполнять дамп частных страниц DAX.
бит 8 (начиная с Linux 4.4)
Выполнять дамп общих страниц DAX.

По умолчанию, установлены следующие биты: 0, 1, 4 (если включён параметр настройки
ядра CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS) и 5. Данное значение может быть
изменено при запуске системы через параметр загрузки coredump_filter.

Значения этого файла отображается в шестнадцатеричной системе счисления (то есть
значение по умолчанию выглядит как 33).

Для страниц ввода-вывода, отображённых в память, таких как фрейм-буфер, дамп
никогда не выполняется, а виртуальные страницы DSO попадают в дамп всегда,
независимо от значения coredump_filter.

Дочерний процесс, созданный fork(2), наследует значение coredump_filter родителя;
значение coredump_filter сохраняется и при execve(2).

Полезно указывать значение coredump_filter в родительской оболочке до запуска
программы, например:

$ echo 0x7 > /proc/self/coredump_filter
$ ./какая-то_программа

Этот файл есть в системе только, если ядро было собрано с параметром настройки
CONFIG_ELF_CORE.

Файлы дампа и systemd
В системах с systemd(1) в качестве init файлы дампа могут помещаться в каталог,
определяемый systemd(1). Для этого systemd(1) использует свойство core_pattern,
которое позволяет передавать дампы в файл по каналу. Это происходит, если файлы
дампа передаются по каналу в программу systemd-coredump(8):

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

В этом случае файлы дампа будут помещаться согласно настройкам
systemd-coredump(8), обычно в виде сжатых lz4(1) файлов в каталог
/var/lib/systemd/coredump/. Список файлов дампа, записанных systemd-coredump(8),
можно получить с помощью coredumpctl(1):

$ coredumpctl list | tail -5
Wed 2017-10-11 22:25:30 CEST 2748 1000 1000 3 present /usr/bin/sleep
Thu 2017-10-12 06:29:10 CEST 2716 1000 1000 3 present /usr/bin/sleep
Thu 2017-10-12 06:30:50 CEST 2767 1000 1000 3 present /usr/bin/sleep
Thu 2017-10-12 06:37:40 CEST 2918 1000 1000 3 present /usr/bin/cat
Thu 2017-10-12 08:13:07 CEST 2955 1000 1000 3 present /usr/bin/cat

Информация, показываемая для каждого дампа включает дату и время дампа, PID, UID и
GID процесса дампа, номер сигнала, вызвавшего дамп, и путь к исполняемому файлу,
который был запущен процессом дампа. Различные параметры coredumpctl(1) позволяют
выбрать файл coredump, который нужно записать из расположения systemd(1), в
образом:

# echo "kernel.core_pattern=core.%p" > /etc/sysctl.d/50-coredump.conf
# /lib/systemd/systemd-sysctl

ЗАМЕЧАНИЯ

Команду gdb(1) gcore можно использовать для получения дампа памяти работающего
процесса.

В версии Linux до 26.27 включительно, если для многонитевого процесса (или,
точнее, процесса, который делит свою памяти с другим процессом, созданным с флагом
CLONE_VM через clone(2)) выполняется дамп памяти, то ID процесса всегда
добавляется к имени файла дампа, если ID процесса уже не включён в это имя с
помощью %p в /proc/sys/kernel/core_pattern (это, главным образом, полезно когда
применяется устаревшая реализация LinuxThreads, где каждая нить процесса имеет
свой PID).

ПРИМЕР

Эта программа может использоваться для демонстрации синтаксиса канала в файле
/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]=</home/mtk/core_pattern_pipe_test>
argc[1]=<20575>
argc[2]=<UID=1000>
argc[3]=<GID=100>
argc[4]=<sig=3>
Total bytes in core dump: 282624

Исходный код программы

/* core_pattern_pipe_test.c */

#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define BUF_SIZE 1024

int
main(int argc, char *argv[])

snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
chdir(cwd);

/* Записываем вывод в файл "core.info" в этом каталоге */

fp = fopen("core.info", "w+");
if (fp == NULL)
exit(EXIT_FAILURE);

/* Показываем аргументы командной строки, переданные программе
core_pattern */

fprintf(fp, "argc=%d\n", argc);
for (j = 0; j < argc; j++)
fprintf(fp, "argc[%d]=<%s>\n", j, argv[j]);

/* Подсчитываем байты стандартного ввода (дампа памяти) */

tot = 0;
while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)
tot += nread;
fprintf(fp, "Total bytes in core dump: %d\n", tot);

fclose(fp);
exit(EXIT_SUCCESS);
}

СМОТРИТЕ ТАКЖЕ

bash(1), coredumpctl(1), gdb(1), getrlimit(2), mmap(2), prctl(2), sigaction(2),
elf(5), proc(5), pthreads(7), signal(7), systemd-coredump(8)