SystemdDoctor
служба не работает частое коды конфигурация запуск

status=1/FAILURE в systemd

Код 1 назначает не systemd, а сама программа. Он значит только одно: запуск удался, программа поработала и решила завершиться неудачей. Причина в её собственном сообщении, а не в коде: 1/FAILURE — это подпись под ошибкой, а не ошибка.

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

Числа меньше 200 systemd не придумывает: он показывает то, что вернул процесс. Единица — общепринятое «что-то не так», и её возвращают практически все программы: nginx при ошибке в конфигурации, postgres при повреждённом каталоге данных, python при необработанном исключении.

Поэтому искать надо не описание кода, а строки самой службы в журнале — обычно за секунду до строки systemd про exit-code. Если служба ничего не написала, вывод, скорее всего, уходит не в журнал, и это первое, что нужно исправить.

На каком этапе. Ошибка возникает после успешного запуска: процесс существовал, поэтому у него был PID и, как правило, есть сообщения в журнале.

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

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

  1. Ошибка в конфигурации самой программы

    Программа читает свой файл настроек, находит недопустимое значение или отсутствующий обязательный параметр и выходит с кодом 1. Это самая частая причина после правки конфигурации.

  2. Нет доступа к файлу, каталогу или сокету, который нужен программе

    Отказ в доступе программа обычно не переводит в отдельный код, а завершается с единицей, написав Permission denied в свой вывод. Частый источник — ужесточение прав в unit-файле: ProtectSystem=strict, PrivateTmp=yes, ReadOnlyPaths=.

  3. Занятый порт или адрес

    Если программа не может занять порт, она сообщает об этом и выходит с кодом 1. В journalctl это видно как Address already in use. Часто виноват прежний экземпляр той же службы, который не завершился.

  4. Необработанная ошибка в приложении

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

  5. Программа ничего не пишет в журнал

    Некоторые службы пишут только в собственный файл и завершаются молча. Тогда в journalctl видна лишь строка systemd про код 1, и создаётся впечатление, что причины нет.

Диагностика

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

Главная команда для этого кода: ищем не строку systemd, а сообщения самой службы перед ней.

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

Показывает, на каком именно шаге получена единица: ExecStartPre, ExecStart или ExecStop. Это сужает поиск.

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

Ручной запуск от пользователя службы даёт сообщение об ошибке прямо в терминал, без поиска по журналу.

sudo -u app /usr/bin/myapp --config /etc/myapp.conf

Отсеивает вторую версию событий: если unit-файл сам по себе неверен, разбираться в коде программы рано.

systemd-analyze verify myapp.service

Решение

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

1. Ошибка в конфигурации самой программы
Почему происходит
Программа читает свой файл настроек, находит недопустимое значение или отсутствующий обязательный параметр и выходит с кодом 1. Это самая частая причина после правки конфигурации.
Как проверить
Запустите встроенную проверку конфигурации, если она есть: у многих служб это отдельный ключ. 
sudo nginx -t
sudo sshd -t
sudo apachectl configtest
Как исправить
Исправьте то, на что указала проверка, и перезапустите службу. Если правка была в последнюю очередь, сверьтесь с резервной копией файла. 
sudo systemctl restart nginx.service
2. Нет доступа к файлу, каталогу или сокету, который нужен программе
Почему происходит
Отказ в доступе программа обычно не переводит в отдельный код, а завершается с единицей, написав Permission denied в свой вывод. Частый источник — ужесточение прав в unit-файле: ProtectSystem=strict, PrivateTmp=yes, ReadOnlyPaths=.
Как проверить
Найдите в журнале службы строку с отказом и посмотрите, к какому пути она относится. 
journalctl -u myapp.service -n 100 --no-pager | grep -i -E "denied|permission|forbidden"
Как исправить
Дайте доступ пользователю службы или разрешите путь в unit-файле через ReadWritePaths=. Для каталогов в /var лучше использовать StateDirectory= — systemd сам создаст каталог с нужным владельцем.
3. Занятый порт или адрес
Почему происходит
Если программа не может занять порт, она сообщает об этом и выходит с кодом 1. В journalctl это видно как Address already in use. Часто виноват прежний экземпляр той же службы, который не завершился.
Как проверить
Посмотрите, кто держит порт. 
sudo ss -tlnp | grep :8080
Как исправить
Освободите порт или поменяйте его в настройках. Подробный разбор — на странице про занятый адрес.
4. Необработанная ошибка в приложении
Почему происходит
Для своих программ единица чаще всего означает исключение при старте: не подключилась база, нет переменной окружения, отсутствует файл миграций. Трассировка при этом попадает в журнал, если вывод не перенаправлен мимо него.
Как проверить
Смотрите журнал без фильтра по приоритету: трассировки часто идут с уровнем info, а -p err их скрывает. 
journalctl -u myapp.service --since "10 min ago" --no-pager
Как исправить
Разбирайтесь с самим приложением. Чтобы его вывод точно оказался в журнале, не перенаправляйте поток в файл через оболочку, а оставьте StandardOutput=journal (это значение по умолчанию).
5. Программа ничего не пишет в журнал
Почему происходит
Некоторые службы пишут только в собственный файл и завершаются молча. Тогда в journalctl видна лишь строка systemd про код 1, и создаётся впечатление, что причины нет.
Как проверить
Проверьте, задан ли в unit-файле нестандартный StandardOutput=, и поищите собственный файл журнала программы. 
systemctl cat myapp.service | grep -i standard
sudo ls -l /var/log/myapp/
Как исправить
Уберите перенаправление вывода в файл на время разбора или посмотрите собственный журнал программы.

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

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

× nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2026-09-14 11:02:10 MSK; 12s ago
    Process: 9021 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

nginx[9021]: nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/sites-enabled/app.conf:12
systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: nginx.service: Failed with result 'exit-code'.

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

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

Чем 1/FAILURE отличается от 203/EXEC?

При 203 программа не начала работу: systemd не смог её запустить. При 1 она работала и вышла сама. Это разные половины пути, и разбираются они по-разному.

В журнале только строка systemd про код 1 и больше ничего. Что делать?

Значит вывод службы не попадает в журнал. Проверьте StandardOutput= и StandardError= в unit-файле, поищите собственный файл журнала программы, попробуйте запустить её вручную от того же пользователя.

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

  • status=203/EXEC в systemd Код 203/EXEC означает, что systemd не смог выполнить программу из ExecStart=. Разбор причин: путь, права, интерпретатор, синтаксис оболочки.
  • Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
  • Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
  • Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
  • status=2/INVALIDARGUMENT в systemd Код 2/INVALIDARGUMENT: программа сочла аргументы или настройки недопустимыми. Частая причина — лишние кавычки в ExecStart=.
  • Apache: Invalid command — не включён модуль Apache не запускается: директива требует модуль, который не подключён. Как найти нужный модуль и включить.
  • Docker: unable to configure the Docker daemon with file daemon.json Демон Docker не запускается из-за ошибки в /etc/docker/daemon.json: неверный JSON или неизвестный ключ.
  • Exec format error при запуске службы Ошибка формата исполняемого файла: не та архитектура, нет строки #!, повреждённый файл или попытка запустить не программу.

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

Источники

  • systemd.exec(5)
    Код 1 отнесён к классу libc: его возвращает программа, а не systemd.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • exit-status.c: класс EXIT_STATUS_LIBC для кодов 0 и 1 исходный код systemd, systemd main
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на nginx с ошибкой в конфигурации и на службе из python с исключением при старте.     собственная проверка, systemd 255
    сверено 15 сентября 2026