SystemdDoctor
служба не работает состояния сигналы

Failed with result 'signal'

Состояние signal значит, что процесс не вышел сам, а был завершён сигналом — и дамп памяти при этом не сохранялся. Дальше разбор идёт по имени сигнала: TERM обычно посылает systemd при остановке, KILL — ядро или таймаут, SYS — фильтр системных вызовов.

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

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

  1. Сигнал послал systemd при остановке или таймауте

    TERM приходит при systemctl stop, при перезапуске и по истечении таймаута запуска. Это самая частая причина, и она видна по соседним строкам журнала.

  2. Процесс убит ядром или внешней командой

    KILL приходит от OOM-killer, от kill -9 или от сценария обслуживания. Программа не получает управления и ничего не записывает.

  3. Сработало ограничение изоляции

    Сигнал SYS означает запрет системного вызова фильтром seccomp. Служба стартует, но умирает на первой запрещённой операции.

Диагностика

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

Точные значения: код killed и номер сигнала без разбора текста статуса.

systemctl show myapp.service -p Result -p ExecMainCode -p ExecMainStatus

Контекст: остановка по команде выглядит иначе, чем внезапная смерть.

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

Если дампы включены, а в состоянии signal дампа нет, значит сигнал был из тех, что дамп не создают — например TERM или KILL.

coredumpctl list --no-pager | tail -5

Решение

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

1. Сигнал послал systemd при остановке или таймауте
Почему происходит
TERM приходит при systemctl stop, при перезапуске и по истечении таймаута запуска. Это самая частая причина, и она видна по соседним строкам журнала.
Как проверить
Посмотрите имя сигнала и контекст. 
systemctl show myapp.service -p ExecMainCode -p ExecMainStatus -p Result
journalctl -u myapp.service -n 40 --no-pager
Как исправить
Если остановка была штатной, исправлять нечего. Если это таймаут — увеличивайте TimeoutStartSec= или разбирайтесь, почему служба не сообщает о готовности.
2. Процесс убит ядром или внешней командой
Почему происходит
KILL приходит от OOM-killer, от kill -9 или от сценария обслуживания. Программа не получает управления и ничего не записывает.
Как проверить
Поищите след OOM-killer и сравните время с действиями администраторов. 
journalctl -k -b --no-pager | grep -i "killed process"
Как исправить
При нехватке памяти правьте пределы и потребление, при внешних командах — сценарии: остановку службы должен выполнять systemctl.
3. Сработало ограничение изоляции
Почему происходит
Сигнал SYS означает запрет системного вызова фильтром seccomp. Служба стартует, но умирает на первой запрещённой операции.
Как проверить
Посмотрите записи ядра про seccomp. 
journalctl -k -b --no-pager | grep -i seccomp | tail -5
Как исправить
Расширьте SystemCallFilter= нужным набором вызовов вместо полного снятия фильтра.

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

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

× myapp.service - My application
     Active: failed (Result: signal) since Mon 2026-09-15 19:22:41 MSK; 2s ago
   Main PID: 19900 (code=killed, signal=KILL)

systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
systemd[1]: myapp.service: Failed with result 'signal'.

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

  • signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
  • signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
  • Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
  • Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
  • Failed with result 'exec-condition' и condition failed Состояния exec-condition и condition failed: запуск не состоялся, потому что условие не выполнено. Это не сбой, а задуманное поведение.
  • Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
  • Failed with result 'protocol' Состояние protocol: служба нарушила договор со systemd. Обычно Type=notify без уведомления или Type=dbus без имени на шине.
  • Failed with result 'resources' Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.

Источники

  • systemd.service(5)
    Значение signal в таблице Result.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на службе, убитой командой kill -9.     собственная проверка, systemd 255
    сверено 15 сентября 2026