COREDUMP_CRASH_DEBUG Linux / DevOps

Сбор дампов падений coredumpctl в systemd: поиск утечек и отладка в GDB

Обновлено: 21.08.2026

Серверные приложения внезапно завершаются с кодом SIGSEGV (Segmentation Fault) или SIGABRT.
Файлы дампов памяти не сохраняются на диск из-за системных лимитов (ulimit -c 0).
Необходимость получения трассировки стека вызовов (Backtrace) упавшего бинарника в production.

1. Установка пакетов отладки

apt-get install -y systemd-coredump gdb || dnf install -y systemd-coredump gdb

2. Конфигурация /etc/systemd/coredump.conf

[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=4G
ExternalSizeMax=20G
KeepFree=15%

systemctl daemon-reload

3. Просмотр собранных дампов аварийных завершений

coredumpctl list
coredumpctl info <PID_или_ИМЯ>

4. Интерактивная отладка в GDB

coredumpctl debug <PID>

Основные команды внутри GDB:

(gdb) bt full
(gdb) info registers
(gdb) thread apply all bt

5. Экспорт дампа для разработчиков

coredumpctl dump <PID> --output /tmp/app_crash.core

Практический опыт инженера: Хранение Core Dumps на медленных дисках может вызвать длительный I/O freeze упавшего сервиса. Настраивайте Storage=external с компрессией Zstandard и лимитом ExternalSizeMax.

Частые вопросы (FAQ)

Почему coredumpctl list пуст после падения программы?

Проверьте параметр sysctl kernel.core_pattern (он должен указывать на |/usr/lib/systemd/systemd-coredump) и лимит cgroups LimitCORE=infinity в systemd сервисе.

Как включить сбор символов для системных библиотек?

Установите debuginfo/dbgsym пакеты для вашего дистрибутива (например, debuginfod-find или dnf debuginfo-install).