Сервис упал с SIGSEGV: сохраняем core и данные запуска

В статусе службы видно code=dumped, signal=SEGV, а после автоматического перезапуска она снова работает. Повторить ошибку пока не удаётся. Если systemd-coredump сохранил данные, можно исследовать состояние упавшего процесса. Главное — выбрать правильный экземпляр и не потерять соответствующий бинарник.

Найти запись инцидента

coredumpctl list --since "2026-11-02 20:00:00"
coredumpctl info 4321
journalctl -u worker.service --since "2026-11-02 20:00:00" --until "2026-11-02 21:00:00" --no-pager

4321 — PID упавшего процесса, выбранный по времени, пути EXE и загрузке. PID может использоваться повторно, поэтому не берите первое совпадение без остальных полей. В info смотрите сигнал, executable, командную строку, unit, время и состояние хранения дампа.

Наличие строки list не гарантирует, что полный core ещё доступен. Метаданные могут сохраниться в журнале, когда внешний файл уже удалён, либо дамп мог быть усечён. Это влияет на следующий шаг: текстовая запись о падении и пригодный для отладчика образ памяти дают разный объём сведений.

Сохранить выбранные данные

coredumpctl dump 4321 --output=/srv/incident/worker.core
coredumpctl debug 4321

Каталог назначения заранее создаётся с ограниченным доступом и достаточным местом. Эти команды относятся к выбранному сохранённому падению; они не вызывают новое. debug запускает отладчик по доступной конфигурации, обычно gdb. Возможности выбора и выгрузки описаны в coredumpctl.

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

Сопоставить версию программы

Сохраните точный executable, build ID, версию пакета и необходимые библиотеки от момента падения. После обновления системы текущий бинарник может уже не соответствовать core. Тогда отладчик покажет неверные адреса, неизвестные функции или некорректный стек. Отладочные символы должны относиться к той же сборке.

Например, служба упала в 20:14 на версии 4.2.1, в 20:20 её обновили до 4.2.2. Анализ core с сегодняшним /usr/bin/worker требует проверки совпадения сборок. Лучше сохранить артефакт релиза сразу, пока расследование ещё связано с конкретным развёртыванием.

Если полного дампа нет

Проверьте LimitCORE у процесса и настройки systemd-coredump: правила хранения, максимальные размеры, место на диске и kernel.core_pattern. В разных дистрибутивах обработчик может быть другим. Не включайте неограниченный сбор на всех службах без оценки объёма и чувствительности памяти.

Тестовое падение проводите только в отдельной лаборатории с учебной программой. На рабочем сервисе настройку проверяют по доступным параметрам и следующему естественному инциденту либо согласованному специализированному тесту. Наличие coredumpctl само по себе не доказывает, что будущий core будет сохранён целиком.

Передать воспроизводимый пакет фактов

Разработчику нужны время, unit, версия, сигнал, стек, краткое описание нагрузки и доступ к подходящим артефактам. Один текст «SIGSEGV» указывает класс завершения, но не место ошибки. В курсе Linux и Bash для DevOps-инженеров работа с процессами и журналами помогает собирать такой контекст. Откройте программу, чтобы увереннее переходить от сообщения о падении к проверяемым данным.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён