SystemdDoctor
мешает работе сигналы остановка

signal=INT и signal=QUIT в systemd

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

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

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

  1. Программа запущена в терминале, а не через systemd

    Нажатие Ctrl+C посылает INT всей группе процессов терминала. Если служба фактически запущена из сеанса, она умрёт вместе с ним.

  2. Сигнал послан сценарием обслуживания

    Сценарии развёртывания иногда завершают процессы напрямую вместо обращения к systemd, а KillSignal= в unit-файле при этом не учитывается.

  3. Указан нестандартный KillSignal=

    Если в unit-файле задан KillSignal=SIGQUIT, обычная остановка службы будет выглядеть как завершение по QUIT. Для некоторых служб это осознанное решение: например так делают корректное завершение с ожиданием запросов.

Диагностика

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

Какие сигналы использует systemd при остановке именно этой службы.

systemctl show myapp.service -p KillSignal -p FinalKillSignal -p KillMode

Была ли рядом команда остановки: это отличает штатное завершение от внешнего сигнала.

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

Решение

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

1. Программа запущена в терминале, а не через systemd
Почему происходит
Нажатие Ctrl+C посылает INT всей группе процессов терминала. Если служба фактически запущена из сеанса, она умрёт вместе с ним.
Как проверить
Посмотрите, чей это процесс и в какой контрольной группе он находится. 
systemd-cgls --no-pager | grep -B3 myapp
systemctl status myapp.service | head -10
Как исправить
Запускайте службу через systemd. Для отладочных запусков используйте systemd-run --unit=test-myapp, тогда процесс не будет привязан к терминалу.
2. Сигнал послан сценарием обслуживания
Почему происходит
Сценарии развёртывания иногда завершают процессы напрямую вместо обращения к systemd, а KillSignal= в unit-файле при этом не учитывается.
Как проверить
Поищите в журнале, что происходило в тот момент. 
journalctl --since "15 min ago" --no-pager | tail -40
Как исправить
Замените в сценариях прямую посылку сигналов на systemctl stop и systemctl restart.
3. Указан нестандартный KillSignal=
Почему происходит
Если в unit-файле задан KillSignal=SIGQUIT, обычная остановка службы будет выглядеть как завершение по QUIT. Для некоторых служб это осознанное решение: например так делают корректное завершение с ожиданием запросов.
Как проверить
Посмотрите параметр. 
systemctl show myapp.service -p KillSignal -p FinalKillSignal
Как исправить
Ничего исправлять не нужно, если это задумано. Убедитесь только, что TimeoutStopSec= даёт программе достаточно времени.

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

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

○ web.service - Web server
     Active: inactive (dead) since Mon 2026-09-15 17:41:09 MSK; 3s ago
   Main PID: 18200 (code=killed, signal=QUIT)

systemd[1]: Stopping web.service - Web server...
systemd[1]: web.service: Main process exited, code=killed, status=3/QUIT
systemd[1]: web.service: Deactivated successfully.

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

  • signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
  • signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
  • Failed with result 'signal' Состояние signal: процесс службы завершён сигналом без сохранения дампа. Как узнать, каким сигналом и от кого.
  • No such process при остановке или сигнале Ошибка 3: процесса с таким номером нет. Разбор для команд остановки и подстановки номера процесса.
  • Target is busy: точка монтирования занята Не удаётся отмонтировать: target is busy. Как найти процессы, которые держат точку монтирования, и корректно освободить её.
  • signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
  • signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
  • signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.

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

Источники

  • systemd.kill(5)
    KillSignal=, FinalKillSignal= и что systemd посылает при остановке.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на unit с KillSignal=SIGQUIT: остановка отражается как завершение по QUIT.     собственная проверка, systemd 255
    сверено 15 сентября 2026