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

signal=HUP (status=1/HUP) в systemd

HUP исторически означал «оборвался терминал», а в службах используется как «перечитай настройки». Если служба от него умирает, значит она этот сигнал не поддерживает, а кто-то — чаще всего ExecReload= — его послал.

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

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

  1. ExecReload= посылает HUP программе, которая его не поддерживает

    Шаблонная строка ExecReload=/bin/kill -HUP $MAINPID попадает в unit-файлы по инерции. Программа, не умеющая перечитывать настройки, завершается по умолчанию.

  2. Сигнал послан вместе с завершением сеанса

    Программа, запущенная не через systemd, а из терминала, получает HUP при выходе. Для служб это признак того, что процесс живёт вне unit-файла.

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

    Часть программ трактует HUP как «завершиться после текущей задачи». Тогда это не сбой, а поведение по задумке.

Диагностика

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

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

systemctl cat myapp.service

Что служба сделала перед завершением: reload или выход.

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

Решение

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

1. ExecReload= посылает HUP программе, которая его не поддерживает
Почему происходит
Шаблонная строка ExecReload=/bin/kill -HUP $MAINPID попадает в unit-файлы по инерции. Программа, не умеющая перечитывать настройки, завершается по умолчанию.
Как проверить
Посмотрите, что делает команда перезагрузки настроек. 
systemctl cat myapp.service | grep -i execreload
Как исправить
Уберите ExecReload= и перезапускайте службу полностью, либо укажите тот способ, который программа действительно поддерживает. 
ExecReload=/usr/local/bin/myapp reload
2. Сигнал послан вместе с завершением сеанса
Почему происходит
Программа, запущенная не через systemd, а из терминала, получает HUP при выходе. Для служб это признак того, что процесс живёт вне unit-файла.
Как проверить
Проверьте, что процесс действительно принадлежит службе. 
systemctl status myapp.service -l --no-pager | head -12
ps -o pid,ppid,cmd -C myapp
Как исправить
Запускайте программу через systemd, а не из терминала. Для разовых запусков есть systemd-run, который создаёт временный unit.
3. Обработчик сигнала внутри программы завершает работу намеренно
Почему происходит
Часть программ трактует HUP как «завершиться после текущей задачи». Тогда это не сбой, а поведение по задумке.
Как проверить
Посмотрите документацию программы и её сообщения перед выходом. 
journalctl -u myapp.service -n 30 --no-pager
Как исправить
Замените перезагрузку настроек на перезапуск службы: для такой программы это единственный корректный способ применить изменения.

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

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

× myapp.service - My application
     Active: failed (Result: signal) since Mon 2026-09-15 17:20:41 MSK; 2s ago
   Main PID: 17800 (code=killed, signal=HUP)

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

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

  • status=3/NOTIMPLEMENTED в systemd Код 3/NOTIMPLEMENTED по соглашению LSB: запрошенное действие не поддерживается. Обычно это reload у службы, которая его не умеет.
  • Failed with result 'signal' Состояние signal: процесс службы завершён сигналом без сохранения дампа. Как узнать, каким сигналом и от кого.
  • signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
  • signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
  • signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
  • signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
  • signal=ILL (status=4/ILL) в systemd Процесс службы завершён сигналом ILL: недопустимая инструкция процессора. Обычно сборка не под этот процессор.
  • signal=INT и signal=QUIT в systemd Процесс службы завершён сигналом INT или QUIT. Кто их посылает службам и почему это обычно не systemd.

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

Источники

  • systemd.service(5)
    ExecReload= и подстановка $MAINPID.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на программе без обработки HUP с шаблонным ExecReload.     собственная проверка, systemd 255
    сверено 15 сентября 2026