SystemdDoctor
мешает работе состояния результата конфигурация

Failed with result «success»: странное сочетание в журнале

Сочетание сбоя с результатом «успех» выглядит противоречиво, но объясняется просто: процесс завершился нулевым кодом, а systemd ожидал, что служба продолжит работать. Результат описывает завершение процесса, а состояние — ожидания в описании unit.

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

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

  1. Тип службы не соответствует поведению программы

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

  2. Оставаться активной после завершения не задано

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

  3. Служба остановлена извне, а не упала

    Результат «успех» бывает и при штатной остановке. Тогда искать сбой не нужно вовсе.

Диагностика

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

Тип службы и точные значения результата и кода завершения.

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

Последовательность событий: завершение, остановка, перезапуск.

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

Сохранение состояния и конфликтующие unit.

systemctl show myapp.service -p RemainAfterExit -p ConflictedBy

Решение

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

1. Тип службы не соответствует поведению программы
Почему происходит
Программа ушла в фон и завершила исходный процесс нулевым кодом. Для простого типа это конец службы.
Как проверить
Посмотрите тип службы и коды завершения. 
systemctl show myapp.service -p Type -p Result -p ExecMainCode -p ExecMainStatus
Как исправить
Приведите тип в соответствие с поведением программы или запретите ей уходить в фон. Для программ с фоновым режимом нужен другой тип или отключение фона.
2. Оставаться активной после завершения не задано
Почему происходит
Для одноразовых задач завершение нормально, но состояние станет неактивным. Если от службы ждут активного состояния, нужен отдельный параметр.
Как проверить
Посмотрите тип и параметр сохранения состояния. 
systemctl show myapp.service -p Type -p RemainAfterExit
Как исправить
Задайте сохранение активного состояния после завершения для одноразовых задач, чей результат должен быть виден. 
[Service]
Type=oneshot
RemainAfterExit=yes
3. Служба остановлена извне, а не упала
Почему происходит
Результат «успех» бывает и при штатной остановке. Тогда искать сбой не нужно вовсе.
Как проверить
Посмотрите, кто остановил службу. 
journalctl -u myapp.service -n 30 --no-pager | grep -iE "Stopping|Stopped|Deactivated"
Как исправить
Проверьте, не остановил ли службу другой unit через конфликт или зависимость. Это частая причина «внезапных» остановок без ошибок.

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

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

systemd[1]: myapp.service: Succeeded.
systemd[1]: myapp.service: Failed with result 'success'.
systemd[1]: Stopped myapp.service - My application.

$ systemctl show myapp.service -p Type -p Result
Type=notify
Result=success

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

Источники

  • systemd.service(5)
    Типы служб и их ожидания от процесса.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на systemd 255: сочетание возникает при несоответствии типа поведению программы.     собственная проверка, systemd 255
    сверено 15 сентября 2026