status=0/SUCCESS, но служба считается упавшей

Что это значит

systemd следит за главным процессом службы. Если тот завершился с нулём, при Type=simple служба переходит в состояние inactive (dead) — успешно, но не работает. А при Type=forking без PIDFile= systemd может потерять настоящий процесс и решить, что служба упала.

Отсюда правило: старый init-скрипт, который сам уходил в фон, нельзя переносить в unit-файл дословно. Либо отключайте демонизацию у программы и берите Type=simple, либо оставляйте её и честно объявляйте Type=forking с PIDFile=.

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

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

1. Программа демонизируется, а в unit-файле Type=simple

   Исходный процесс создаёт дочерний и завершается. systemd видит успешный выход главного процесса и считает службу отработавшей.

2. Одноразовая задача без RemainAfterExit=

   Для Type=oneshot завершение — это норма. Служба уходит в inactive (dead), и если её опрашивает мониторинг как «должна быть active», он поднимет тревогу на ровном месте.

3. Служба завершает работу, потому что ей нечего делать

   Программа считает, что всё сделано: не нашла работы, отработала одну итерацию, вышла по настройке. Код нулевой, претензий у systemd нет — но служба не работает.

Диагностика

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

systemctl show myapp.service -p Type -p RemainAfterExit -p PIDFile -p GuessMainPID

systemctl status myapp.service -l --no-pager

ps -ef --forest | grep -A3 myapp

Решение

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

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

○ myapp.service - My application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; preset: enabled)
     Active: inactive (dead) since Mon 2026-09-15 11:02:31 MSK; 5s ago
    Process: 8100 ExecStart=/usr/sbin/myapp --daemon (code=exited, status=0/SUCCESS)
   Main PID: 8100 (code=exited, status=0/SUCCESS)

systemd[1]: myapp.service: Deactivated successfully.

Обратите внимание на кружок вместо крестика и на «Deactivated successfully»: с точки зрения systemd ошибки не было вовсе.

Частые вопросы

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

• Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
• status=1/FAILURE в systemd Код 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
• Redis: служба сразу останавливается из-за daemonize yes Redis уходит в фон сам, systemd теряет процесс и считает службу отработавшей. Как настроить правильно.
• A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
• Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
• Apache: Invalid command — не включён модуль Apache не запускается: директива требует модуль, который не подключён. Как найти нужный модуль и включить.
• Cannot assign requested address при привязке Ошибка 99 при привязке: адрес не принадлежит машине или ещё не поднят. Разбор с network-online.target и ip_nonlocal_bind.
• Connection refused в журнале службы Соединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.

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

• nginx.service 7
• redis-server.service 6

Источники

• systemd.service(5)
  Type=simple, forking, oneshot и RemainAfterExit=: как systemd определяет, что служба работает. официальная документация, systemd 255
  сверено 15 сентября 2026
• Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
  Воспроизведено на unit с демонизирующейся программой и на oneshot без RemainAfterExit. собственная проверка, systemd 255
  сверено 15 сентября 2026