SystemdDoctor
служба не работает частое разбор

Failed to start … — что делать с общим сообщением

Строка Failed to start ИМЯ — это итог, который systemd печатает после неудачи. Причина всегда выше: код выхода, сигнал, таймаут или неудача зависимости. Разбор начинается с поиска этих строк, а не с самой этой.

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

Порядок простой. Сначала systemctl status — он даёт состояние результата и код. Затем journalctl -xeu — там сообщения самой службы. И только потом, если ничего не нашлось, общий порядок действий: проверка unit-файла, прав, путей.

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

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

  1. Выше в журнале есть код выхода или сигнал

    Это и есть причина. Число до 200 назначила программа, 200 и выше — systemd, не сумев подготовить запуск.

  2. Неудача зависимости

    Если рядом есть строка «Dependency failed for», ваша служба не запускалась вовсе. Разбирать надо зависимость.

  3. Ничего больше в журнале нет

    Служба может писать в собственный файл или подавлять вывод. Тогда в журнале только строки systemd.

Диагностика

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

Состояние результата, код и последние строки — основа разбора.

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

Сообщения службы с пояснениями systemd.

journalctl -xeu myapp.service --no-pager -n 60

Не упала ли зависимость: тогда причина в другом unit.

systemctl --failed --no-pager

Решение

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

1. Выше в журнале есть код выхода или сигнал
Почему происходит
Это и есть причина. Число до 200 назначила программа, 200 и выше — systemd, не сумев подготовить запуск.
Как проверить
Найдите строку с кодом. 
systemctl status myapp.service -l --no-pager | grep -E "status=|signal=|Result:"
Как исправить
Разбирайте найденный код: на этом сайте для каждого есть отдельная запись с причинами и решением.
2. Неудача зависимости
Почему происходит
Если рядом есть строка «Dependency failed for», ваша служба не запускалась вовсе. Разбирать надо зависимость.
Как проверить
Посмотрите упавшие unit. 
systemctl --failed --no-pager
systemctl list-dependencies myapp.service --no-pager | head -20
Как исправить
Найдите первую упавшую зависимость в цепочке и разбирайтесь с ней.
3. Ничего больше в журнале нет
Почему происходит
Служба может писать в собственный файл или подавлять вывод. Тогда в журнале только строки systemd.
Как проверить
Посмотрите настройки вывода и собственные журналы программы. 
systemctl show myapp.service -p StandardOutput -p StandardError
sudo ls -l /var/log/myapp/ 2>/dev/null
Как исправить
Верните вывод в журнал (StandardOutput=journal) или прочитайте собственный файл программы. Для разбора можно запустить программу вручную от пользователя службы.

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

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

myapp[4500]: fatal: cannot open /etc/myapp/config.yml: permission denied
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: myapp.service: Failed with result 'exit-code'.
systemd[1]: Failed to start myapp.service - My application.

Полезная строка здесь первая, а не последняя. Именно поэтому журнал читают снизу вверх, начиная с итога и поднимаясь к причине.

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

Источники

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