coredumpctl: найти падение бинаря

Что такое coredumpctl и как он работает

Когда бинарь падает с SEGV, ядро может сохранить core dump — снимок памяти процесса в момент креша. В systemd-based дистрибутивах за сбор, хранение и поиск этих дампов отвечёт coredumpctl, обёртка над systemd-coredump. Он хранит дампы в /var/lib/systemd/coredump/ и индексирует метаданные через journald.

Установка тривиальна для большинства дистрибутивов:

# Debian/Ubuntu
sudo apt install systemd-coredump

# RHEL/Fedora
sudo dnf install systemd-coredump

После установки убедись, что kernel.core_pattern указывает на pipe в systemd-coredump:

cat /proc/sys/kernel/core_pattern
# ожидаемо: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e

Если стоит core.%e.%p — дампы пишутся в файлы, и coredumpctl их не видит.

Просмотр списка дампов: coredumpctl list

Базовая команда выводит все сохранённые падения:

coredumpctl list

Вывод содержит столбцы: MESSAGE ID, TIMESTAMP, PID, UID, GID, COMM, EXE, COREFILE.

Ключевые флаги list:

Детали падения: coredumpctl info

Для одного дампа info выдаёт всё, что нужно перед тем как тянуть файл:

coredumpctl info 1234

Где 1234 — PID процесса или номер из list. Вывод включает:

• сигнал, вызвавший падение (SIGSEGV, SIGABRT и т.д.)
• время и дату
• путь к исполняемому файлу
• размер core-файла
• MESSAGE ID — корреляция с journald

# Пример вывода (ключевые строки)
         PID: 1234 (myapp)
     UID:GID: 1000:1000
      Signal: 11 (SIGSEGV)
    Timestamp: Mon 2025-01-06 14:23:01 UTC
     Command Line: /opt/myapp/bin/myapp --config prod.yaml
     Executable: /opt/myapp/bin/myapp
       Core File: /var/lib/systemd/coredump/myapp.1234.abc123.core

Извлечение core-файла: coredumpctl dump

Извлекаемый файл можно отправить прямо в gdb или сохранить на диск:

# Сохранить в текущую директорию
coredumpctl dump 1234 --output=myapp.core

# Прямая подача в gdb
coredumpctl dump 1234 -o - | gdb /opt/myapp/bin/myapp -

Фильтрация и поиск по бинару, PID, времени

В реальной эксплуатации дампов накапливается десятки, и искать по PID неудобно. coredumpctl поддерживает несколько фильтров одновременно:

# Все падения конкретного бинара
coredumpctl list --exe /opt/myapp/bin/myapp

# Падения за последний час
coredumpctl list --since "1 hour ago"

# По конкретному пользователю и бинару
coredumpctl list --exe /usr/bin/python3 --uid 1000

# Только SIGSEGV
coredumpctl list --signal 11

Для скриптов и автоматизации удобно использовать JSON:

coredumpctl list --json=short | jq '.[] | select(.exe == "/opt/myapp/bin/myapp") | .pid'

Практические примеры отладки падений

Типичный цикл отладки выглядит так:

# 1. Находим последнее падение myapp
coredumpctl list --exe /opt/myapp/bin/myapp -n 1

# 2. Смотрим детали — какой сигнал и где
coredumpctl info <PID>

# 3. Тянем core и запускаем gdb
coredumpctl dump <PID> --output=/tmp/myapp.core
gdb /opt/myapp/bin/myapp /tmp/myapp.core

# 4. В gdb:
(gdb) bt full
(gdb) info registers
(gdb) x/16i $pc

Если дамп не появляется — проверь coredumpctl list и journalctl -u systemd-coredump. Частая причина: LimitCORE в systemd-unit выставлен в 0, или kernel.core_pattern не настроен на pipe.

[Service]
LimitCORE=infinity