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

signal=ILL (status=4/ILL) в systemd

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

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

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

  1. Сборка требует инструкций, которых нет у процессора

    Сборки «под современные процессоры» используют расширенные наборы инструкций. На старом процессоре или в виртуальной машине с ограниченным набором такие инструкции недопустимы.

  2. Виртуальная машина скрывает часть возможностей процессора

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

  3. Повреждённый исполняемый файл

    Недокачанный или частично перезаписанный файл может содержать мусор на месте инструкций.

Диагностика

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

Подтверждает сигнал и момент падения.

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

Модель процессора и набор инструкций машины.

lscpu | head -20

Трассировка покажет, в какой библиотеке встретилась недопустимая инструкция.

coredumpctl info myapp | head -30

Решение

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

1. Сборка требует инструкций, которых нет у процессора
Почему происходит
Сборки «под современные процессоры» используют расширенные наборы инструкций. На старом процессоре или в виртуальной машине с ограниченным набором такие инструкции недопустимы.
Как проверить
Сравните набор инструкций процессора с требованиями сборки.
grep -m1 flags /proc/cpuinfo | tr " " "\n" | grep -E "avx|avx2|avx512|sse4" | head
file /usr/local/bin/myapp
Как исправить
Поставьте сборку под общий набор инструкций (для x86-64 это базовый уровень) или соберите программу на этой же машине.
2. Виртуальная машина скрывает часть возможностей процессора
Почему происходит
При миграции между узлами гипервизор может предъявлять урезанный набор инструкций. Программа, работавшая до переноса, начинает падать после.
Как проверить
Посмотрите модель процессора, которую видит система, и тип виртуализации.
systemd-detect-virt
lscpu | grep -E "Model name|Flags" | head -2
Как исправить
Согласуйте с администратором гипервизора модель процессора для виртуальной машины либо используйте сборку под базовый набор инструкций.
3. Повреждённый исполняемый файл
Почему происходит
Недокачанный или частично перезаписанный файл может содержать мусор на месте инструкций.
Как проверить
Проверьте целостность файла средствами пакетного менеджера или сверьте контрольную сумму.
sha256sum /usr/local/bin/myapp
dpkg -V 2>/dev/null | head
Как исправить
Скачайте и установите файл заново, сверив контрольную сумму.

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

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

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

kernel: traps: myapp[15600] trap invalid opcode ip:55e9c1a2b0 sp:7ffd2 error:0
systemd[1]: myapp.service: Main process exited, code=dumped, signal=ILL

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

  • Exec format error при запуске службы Ошибка формата исполняемого файла: не та архитектура, нет строки #!, повреждённый файл или попытка запустить не программу.
  • signal=SEGV (status=11/SEGV) в systemd Процесс службы завершён сигналом SEGV: обращение к недопустимой памяти. Как собрать дамп и что смотреть.
  • status=230/PERSONALITY в systemd Код 230/PERSONALITY: не удалось задать домен исполнения из Personality=. Обычно запрошена архитектура, недоступная на машине.
  • signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
  • signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
  • signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
  • Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
  • Failed with result 'signal' Состояние signal: процесс службы завершён сигналом без сохранения дампа. Как узнать, каким сигналом и от кого.

Источники

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