SystemdDoctor
служба не работает состояния падение дампы

Failed with result 'core-dump'

Состояние core-dump значит, что процесс упал по сигналу, создающему дамп — обычно SEGV, ABRT, BUS или FPE, — и дамп был сохранён. Это удобный случай: причина падения записана, её можно прочитать, а не угадывать.

Что это значит

На системах с systemd-coredump дампы попадают под управление journald и доступны через coredumpctl. Там же лежит трассировка стека, которой обычно достаточно, чтобы понять, в какой библиотеке случилось падение.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Дефект в программе или её расширении

    Аварийное завершение по SEGV или ABRT — всегда следствие ошибки в коде. Чаще падает подключаемый модуль, а не сама служба.

  2. Несовместимость библиотек после обновления системы

    Программа собрана под одну версию библиотеки, а установлена другая. Падение начинается сразу после обновления пакетов.

  3. Дамп не сохраняется, и разбирать нечего

    Если LimitCORE=0 или в системе не настроен приёмник дампов, состояние будет core-dump, а самого дампа не будет. Тогда причину падения приходится искать по сообщениям программы.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Список дампов: видно, единичное это падение или повторяющееся.

coredumpctl list --no-pager | tail -10

Трассировка стека и сигнал — основа разбора.

coredumpctl info myapp | head -40

Открывает дамп в отладчике, когда трассировки недостаточно. Требует установленного gdb и отладочных символов.

coredumpctl debug myapp

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Дефект в программе или её расширении
Почему происходит
Аварийное завершение по SEGV или ABRT — всегда следствие ошибки в коде. Чаще падает подключаемый модуль, а не сама служба.
Как проверить
Откройте трассировку последнего дампа. 
coredumpctl list --no-pager | tail -5
coredumpctl info | head -40
Как исправить
Обновите или отключите виновный модуль, обновите программу. Трассировку стоит приложить к сообщению об ошибке разработчикам.
2. Несовместимость библиотек после обновления системы
Почему происходит
Программа собрана под одну версию библиотеки, а установлена другая. Падение начинается сразу после обновления пакетов.
Как проверить
Сопоставьте время падений и время обновления пакетов. 
coredumpctl list --no-pager | tail -5
grep -iE " upgrade | install " /var/log/dpkg.log 2>/dev/null | tail -10
Как исправить
Пересоберите или переустановите программу под текущие библиотеки.
3. Дамп не сохраняется, и разбирать нечего
Почему происходит
Если LimitCORE=0 или в системе не настроен приёмник дампов, состояние будет core-dump, а самого дампа не будет. Тогда причину падения приходится искать по сообщениям программы.
Как проверить
Посмотрите предел и приёмник дампов. 
systemctl show myapp.service -p LimitCORE
cat /proc/sys/kernel/core_pattern
Как исправить
Разрешите дампы для разбора: LimitCORE=infinity в unit-файле и установленный systemd-coredump. После разбора ограничение можно вернуть. 
sudo systemctl edit myapp.service   # LimitCORE=infinity

Пример вывода

Служба упала с сохранением дампа. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

× myapp.service - My application
     Active: failed (Result: core-dump) since Mon 2026-09-15 19:44:03 MSK; 30s ago
   Main PID: 20300 (code=dumped, signal=SEGV)

systemd-coredump[20308]: Process 20300 (myapp) of user 995 dumped core.
systemd[1]: myapp.service: Failed with result 'core-dump'.

Связанные ошибки

  • signal=SEGV (status=11/SEGV) в systemd Процесс службы завершён сигналом SEGV: обращение к недопустимой памяти. Как собрать дамп и что смотреть.
  • signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
  • signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
  • signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
  • Failed with result 'exec-condition' и condition failed Состояния exec-condition и condition failed: запуск не состоялся, потому что условие не выполнено. Это не сбой, а задуманное поведение.
  • Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
  • Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
  • Failed with result 'protocol' Состояние protocol: служба нарушила договор со systemd. Обычно Type=notify без уведомления или Type=dbus без имени на шине.

Где встречается чаще всего

Источники

  • coredumpctl(1)
    Просмотр дампов, трассировок и запуск отладчика.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.service(5)
    Значение core-dump в таблице Result.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на намеренно падающей программе с включённым systemd-coredump.     собственная проверка, systemd 255
    сверено 15 сентября 2026