Настройка 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 | #практика 
