Настройка coredump в Linux — диагностика падений процессов!

Когда Linux-процесс аварийно завершается (например, SIGSEGV / Segmentation fault, SIGABRT и др.), система может сохранить снимок памяти процесса — core dump.

Без dump-файла обычно остаётся только сам факт падения и запись в логах. Core dump позволяет открыть состояние процесса в gdb, получить stack trace, посмотреть память, регистры, потоки и локализовать причину уже после завершения процесса.

Проверка текущего лимита на создание dump:

ulimit -c

Если вывод 0 — сохранение core dump отключено для текущей shell/session.

Временное включение:

ulimit -c unlimited

Это работает только для процессов, запущенных из текущей shell-сессии. После logout или reboot настройка пропадёт.

Для systemd-сервисов одного ulimit недостаточно — лимит нужно задавать в unit-файле:

[Service]
LimitCORE=infinity

После изменения unit-файла:

sudo systemctl daemon-reload
sudo systemctl restart app.service

Теперь проверяем, как именно система сохраняет dump-файлы:

cat /proc/sys/kernel/core_pattern

Параметр core_pattern определяет обработчик и путь сохранения dump. Если значение начинается с |, dump передаётся внешнему обработчику, например systemd-coredump.

Пример прямого сохранения dump в файл:

/core.%e.%p.%t

Где: %e — имя процесса; %p — PID процесса; %t — UNIX timestamp

Создадим каталог для dump-файлов и настроим сохранение:

sudo mkdir -p /var/crash
sudo chmod 1777 /var/crash
sudo sysctl -w kernel.core_pattern=/var/crash/core.%e.%p.%t

1777 используется как простой демо вариант для тестов и локальной диагностики. В продакшен обычно делают более жёсткие права доступа и отдельно контролируют доступ к dump-файлам, поскольку они могут содержать чувствительные данные процесса.

Чтобы настройка сохранилась после reboot:

sudo nano /etc/sysctl.d/99-coredump.conf

Добавляем:

kernel.core_pattern=/var/crash/core.%e.%p.%t

Применяем конфигурацию:

sudo sysctl --system

Пример аварийного завершения процесса:

./app
Segmentation fault (core dumped)

После падения появится dump-файл:

/var/crash/core.app.18422.1715962012

Теперь можно открыть dump через gdb:

gdb ./app /var/crash/core.app.18422.1715962012

Посмотреть стек вызовов:

(gdb) bt

Для полноценного анализа бинарь желательно собирать с debug symbols (-g) без stripping.

На большинстве современных systemd-дистрибутивов dump часто обрабатывается через systemd-coredump, а не сохраняется напрямую через core_pattern.

Посмотреть список crash:

coredumpctl list

Получить информацию по dump:

coredumpctl info PID

Открыть dump сразу в gdb:

coredumpctl debug PID

Вместо PID можно использовать имя процесса, путь к бинарю и другие фильтры coredumpctl. Также важно помнить, что systemd-coredump отдельно управляет хранением dump-файлов через coredump.conf: Storage, ProcessSizeMax, ExternalSizeMax, MaxUse, KeepFree.

Это особенно важно в проде, где dump может занимать гигабайты и быстро заполнять диск.

🔥 Core dump — один из базовых механизмов low-level диагностики Linux-приложений, backend-сервисов и анализа падений в продакшен.

🚪 Linux Ready | #практика