SystemdDoctor
требует внимания состояния условия загрузка

Failed with result 'exec-condition' и condition failed

Эти два состояния означают, что служба не запускалась осознанно: условие в unit-файле оказалось невыполненным. ConditionPathExists= и родственные параметры дают «condition failed» и пропуск запуска, а команда ExecCondition= с ненулевым кодом — состояние exec-condition.

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

Разница с Assert*= принципиальна: условие приводит к тихому пропуску, а утверждение — к настоящей ошибке с записью в журнал. Если служба должна шумно падать при невыполненном требовании, нужны именно утверждения.

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

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

  1. Условие в unit-файле не выполнено

    Нет файла из ConditionPathExists=, не то окружение в ConditionVirtualization=, не та архитектура. systemd пропускает запуск и сообщает об этом в журнал строкой про условие.

  2. Команда ExecCondition= вернула ненулевой код

    Эта команда решает, запускать службу или нет. Код 1–254 означает «не запускать», а больше 254 — настоящую ошибку.

  3. Условие проверяет путь, который появляется позже

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

Диагностика

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

Все условия и утверждения службы: их часто добавляют и забывают.

systemctl show myapp.service | grep -iE "^Condition|^Assert"

systemd называет невыполненное условие прямо, с путём или значением.

journalctl -u myapp.service -n 20 --no-pager | grep -i "condition"

Пропуск по условию оставляет службу неактивной, но не помечает упавшей — это важно отличать.

systemctl is-active myapp.service; systemctl is-failed myapp.service

Решение

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

1. Условие в unit-файле не выполнено
Почему происходит
Нет файла из ConditionPathExists=, не то окружение в ConditionVirtualization=, не та архитектура. systemd пропускает запуск и сообщает об этом в журнал строкой про условие.
Как проверить
Посмотрите все условия службы и проверьте каждое. 
systemctl show myapp.service | grep -i "^Condition"
journalctl -u myapp.service -n 20 --no-pager | grep -i condition
Как исправить
Либо выполните условие (создайте файл, включите нужное окружение), либо уберите его из unit-файла, если оно потеряло смысл.
2. Команда ExecCondition= вернула ненулевой код
Почему происходит
Эта команда решает, запускать службу или нет. Код 1–254 означает «не запускать», а больше 254 — настоящую ошибку.
Как проверить
Посмотрите команду и запустите её вручную. 
systemctl cat myapp.service | grep -i execcondition
Как исправить
Проверьте логику проверки: она могла сработать не так, как задумано. Помните, что код 255 и выше означает ошибку, а не отказ от запуска.
3. Условие проверяет путь, который появляется позже
Почему происходит
При загрузке служба стартует раньше, чем монтируется раздел или создаётся файл. Условие не выполняется, запуск пропускается, и после загрузки служба не работает без всяких ошибок.
Как проверить
Посмотрите, когда появляется нужный путь, и порядок запуска. 
systemctl list-dependencies --before myapp.service --no-pager | head
findmnt -T /data
Как исправить
Добавьте RequiresMountsFor= или зависимость от службы, создающей путь: тогда условие будет проверяться в подходящий момент.

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

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

○ myapp.service - My application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; preset: enabled)
     Active: inactive (dead)
  Condition: start condition unmet at Mon 2026-09-15 22:30:19 MSK; 5s ago
             └─ ConditionPathExists=/etc/myapp/enabled was not met

systemd[1]: myapp.service: Skipped due to 'exec-condition'.

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

  • Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
  • Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
  • A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
  • Cannot assign requested address при привязке Ошибка 99 при привязке: адрес не принадлежит машине или ещё не поднят. Разбор с network-online.target и ip_nonlocal_bind.
  • Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
  • Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
  • Failed with result 'protocol' Состояние protocol: служба нарушила договор со systemd. Обычно Type=notify без уведомления или Type=dbus без имени на шине.
  • Failed with result 'resources' Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.

Источники

  • systemd.unit(5)
    Условия Condition*= и утверждения Assert*=: разница в поведении.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.service(5)
    ExecCondition= и трактовка кодов возврата.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на unit с ConditionPathExists на несуществующий файл.     собственная проверка, systemd 255
    сверено 15 сентября 2026