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

signal=ABRT (status=6/ABRT) в systemd

ABRT программа посылает себе сама: так работают внутренние проверки, необработанные исключения в C++ и ошибки выделения памяти. В отличие от SEGV это не случайное падение, а осознанное «дальше нельзя» — и почти всегда перед ним есть понятное сообщение.

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

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

  1. Сработала внутренняя проверка программы

    Проверки на недопустимое состояние прерывают работу намеренно. Перед этим программа обычно пишет в вывод название файла и строку исходного кода.

  2. Необработанное исключение

    В программах на C++ выход исключения за пределы обработчиков завершает процесс через ABRT. Строка «terminate called after throwing an instance of» — типичный признак.

  3. Ошибка выделения памяти внутри программы

    При нехватке памяти часть библиотек не возвращает ошибку, а прерывает работу. Тогда ABRT — следствие исчерпанной памяти, и рядом будут признаки нехватки.

Диагностика

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

Сообщение проверки или исключения — оно почти всегда есть и прямо называет причину.

journalctl -u myapp.service -n 60 --no-pager

Трассировка стека: показывает, в какой функции сработала проверка.

coredumpctl info myapp | head -40

Отличает обычный ABRT от последствия нехватки памяти.

systemctl show myapp.service -p Result -p MemoryPeak

Решение

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

1. Сработала внутренняя проверка программы
Почему происходит
Проверки на недопустимое состояние прерывают работу намеренно. Перед этим программа обычно пишет в вывод название файла и строку исходного кода.
Как проверить
Посмотрите последние строки службы перед падением. 
journalctl -u myapp.service -n 40 --no-pager
Как исправить
Читайте сообщение проверки: оно называет причину. Если речь о повреждённых данных, разбирайтесь с ними, а не с самой службой.
2. Необработанное исключение
Почему происходит
В программах на C++ выход исключения за пределы обработчиков завершает процесс через ABRT. Строка «terminate called after throwing an instance of» — типичный признак.
Как проверить
Поищите характерное сообщение в журнале. 
journalctl -u myapp.service -n 60 --no-pager | grep -iE "terminate called|exception|assert"
Как исправить
Причину даёт текст исключения: чаще всего это недоступный файл, неверные настройки или отказ сети. Исправлять нужно её, а не сигнал.
3. Ошибка выделения памяти внутри программы
Почему происходит
При нехватке памяти часть библиотек не возвращает ошибку, а прерывает работу. Тогда ABRT — следствие исчерпанной памяти, и рядом будут признаки нехватки.
Как проверить
Посмотрите память службы и записи ядра. 
systemctl show myapp.service -p MemoryMax -p MemoryPeak
journalctl -k -b --no-pager | grep -i "out of memory"
Как исправить
Поднимите предел памяти или снизьте потребление. Разбор совпадает с разбором нехватки памяти.

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

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

× myapp.service - My application
     Active: failed (Result: core-dump) since Mon 2026-09-15 15:01:32 MSK; 8s ago
   Main PID: 14500 (code=dumped, signal=ABRT)

myapp[14500]: terminate called after throwing an instance of 'std::runtime_error'
myapp[14500]:   what():  cannot open state file /var/lib/myapp/state.db
systemd[1]: myapp.service: Main process exited, code=dumped, signal=ABRT

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

  • signal=SEGV (status=11/SEGV) в systemd Процесс службы завершён сигналом SEGV: обращение к недопустимой памяти. Как собрать дамп и что смотреть.
  • Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
  • status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
  • signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
  • signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
  • signal=ILL (status=4/ILL) в systemd Процесс службы завершён сигналом ILL: недопустимая инструкция процессора. Обычно сборка не под этот процессор.
  • Failed with result 'signal' Состояние signal: процесс службы завершён сигналом без сохранения дампа. Как узнать, каким сигналом и от кого.
  • nginx: worker process exited on signal Рабочий процесс nginx падает: сторонний модуль, нехватка памяти, ошибка в обработке запроса.

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

Источники

  • coredumpctl(1)
    Просмотр дампов и трассировок для разбора аварийных завершений.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на программе с намеренно проваленной внутренней проверкой.     собственная проверка, systemd 255
    сверено 15 сентября 2026