SystemdDoctor
служба не работает разбор первые шаги частое

Job for myapp.service failed: с чего начинать разбор

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

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

В сообщении есть одна полезная деталь — какой процесс завершился с ошибкой. Формулировка про главный процесс означает, что не удался сам запуск программы. Формулировка про вспомогательную команду означает отказ на подготовительном или завершающем шаге: проверке настроек, создании каталога, команде остановки. Это разные ветки разбора, и различать их стоит сразу.

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

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

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

  1. Не удался запуск главного процесса

    Программа не запустилась или сразу завершилась с ненулевым кодом. Код выхода в состоянии службы сразу сужает поиск: 203 — не нашли или не смогли выполнить файл, 217 — нет пользователя, 1 — программа сама сообщила об ошибке.

  2. Не удалась вспомогательная команда

    Отказ на подготовительном шаге происходит до запуска программы, и её журнал при этом пуст. Разбор по журналу программы уходит в пустоту.

  3. Описание unit загружено с ошибкой

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

Диагностика

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

Состояние, код выхода и какой именно процесс завершился с ошибкой.

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

Сообщения самой программы: причина почти всегда здесь.

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

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

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

Проверка описания: покажет ошибки разбора и отброшенные параметры.

systemd-analyze verify /etc/systemd/system/myapp.service

Решение

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

1. Не удался запуск главного процесса
Почему происходит
Программа не запустилась или сразу завершилась с ненулевым кодом. Код выхода в состоянии службы сразу сужает поиск: 203 — не нашли или не смогли выполнить файл, 217 — нет пользователя, 1 — программа сама сообщила об ошибке.
Как проверить
Посмотрите состояние службы и код выхода. 
systemctl status myapp.service -l --no-pager
systemctl show myapp.service -p ExecMainStatus -p Result
Как исправить
Разбирайтесь по коду выхода: у каждого своя короткая ветка проверок. Числа выше двухсот означают, что программа даже не начала работу — виноваты параметры unit-файла.
2. Не удалась вспомогательная команда
Почему происходит
Отказ на подготовительном шаге происходит до запуска программы, и её журнал при этом пуст. Разбор по журналу программы уходит в пустоту.
Как проверить
Посмотрите, какая именно команда вернула ошибку. 
systemctl status myapp.service -l --no-pager | grep -E "Process:|Control"
systemctl show myapp.service -p ExecStartPre -p ExecStop
Как исправить
Запустите вспомогательную команду вручную от того же пользователя: причина станет видна сразу. Часто это проверка настроек, которая и должна была отсечь ошибку.
3. Описание unit загружено с ошибкой
Почему происходит
При фатальной ошибке в описании запуск не начинается вовсе. В журнале при этом есть строка о разборе файла, а не о процессе.
Как проверить
Проверьте описание и посмотрите записи о его разборе. 
systemd-analyze verify /etc/systemd/system/myapp.service 2>&1 | head
journalctl -u myapp.service -n 20 --no-pager | grep -iE "Unit configuration|Unknown key"
Как исправить
Исправьте описание и перечитайте его. Проверка описания отдельной командой ловит такие ошибки до попытки запуска. 
sudo systemctl daemon-reload

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

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

$ sudo systemctl start myapp.service
Job for myapp.service failed because the control process exited with error code.
See "systemctl status myapp.service" and "journalctl -xeu myapp.service" for details.

$ systemctl status myapp.service -l --no-pager | head -6
× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-15 20:04:11 MSK; 3s ago
    Process: 13000 ExecStartPre=/usr/local/bin/myapp --check-config (code=exited, status=78/CONFIG)

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

Источники

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