status=127 в systemd: команда не найдена — причины и решение

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

Отличие от 203/EXEC принципиально. При 203 программу не нашёл сам systemd. При 127 systemd запустил оболочку успешно, а уже она не нашла то, что вы попросили. Значит, проверять надо PATH внутри окружения службы, а не путь в ExecStart=.

PATH у службы короткий и не берётся из вашего профиля. Программы из /usr/local/bin обычно доступны, а вот установленное в домашний каталог или через менеджеры версий вроде nvm — нет.

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

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

Команда внутри скрипта отсутствует в PATH службы

Окружение службы не содержит ваши пользовательские каталоги. То, что работает в терминале, в службе может быть недоступно.
Программа установлена менеджером версий в домашнем каталоге

nvm, pyenv, rbenv и подобные раскладывают программы в домашний каталог пользователя и подключаются через файлы профиля, которые служба не читает.
Скрипт вызывает команду, которой нет в системе

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

Диагностика

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

Оболочка пишет имя ненайденной команды и номер строки скрипта — это точный адрес проблемы.

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

Показывает, запускается ли служба через оболочку и какой PATH ей задан.

systemctl show myapp.service -p ExecStart -p Environment

Проверка доступности команды именно в том PATH, который увидит служба.

sudo -u app env PATH="$(systemctl show-environment | sed -n "s/^PATH=//p")" command -v rsync

Решение

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

1. Команда внутри скрипта отсутствует в PATH службы

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

Как проверить

Посмотрите, какой PATH виден службе, и найдите настоящий путь к команде.

systemctl show-environment | grep -i path
command -v rsync node python3

Как исправить

Пишите в скрипте полные пути или задайте PATH в unit-файле через Environment=.

Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

2. Программа установлена менеджером версий в домашнем каталоге

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

Как проверить

Найдите фактический путь и проверьте доступ от пользователя службы.

sudo -u app bash -lc "command -v node"
ls -l /home/app/.nvm/versions/node/*/bin/node 2>/dev/null

Как исправить: Укажите в unit-файле полный путь к нужной версии или установите программу в системный каталог. Ссылки на «текущую» версию менеджера версий лучше не использовать: они меняются.

3. Скрипт вызывает команду, которой нет в системе

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

Как проверить

Посмотрите строку скрипта из журнала — оболочка называет команду прямо.

journalctl -u myapp.service -n 30 --no-pager | grep -i "not found"

Как исправить: Установите недостающий пакет или уберите вызов из скрипта.

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

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

× backup.service - Nightly backup
     Active: failed (Result: exit-code) since Mon 2026-09-15 02:00:04 MSK; 5s ago
    Process: 11100 ExecStart=/usr/local/bin/backup.sh (code=exited, status=127)

backup.sh[11100]: /usr/local/bin/backup.sh: line 8: rclone: command not found
systemd[1]: backup.service: Main process exited, code=exited, status=127

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

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

При 203 программу не смог запустить systemd — проблема в самом ExecStart. При 127 systemd всё запустил, а команду не нашла оболочка внутри скрипта: проблема в PATH или в отсутствующем пакете.

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

status=203/EXEC в systemd Код 203/EXEC означает, что systemd не смог выполнить программу из ExecStart=. Разбор причин: путь, права, интерпретатор, синтаксис оболочки.
status=126 в systemd: файл не исполняется Код 126: команда найдена, но выполнить её нельзя. Отличие от 127 и от 203/EXEC, разбор причин.
status=255/EXCEPTION в systemd Код 255/EXCEPTION: программа завершилась с кодом 255 либо код используется для передачи аварийного завершения. Как различить случаи.
Exec format error при запуске службы Ошибка формата исполняемого файла: не та архитектура, нет строки #!, повреждённый файл или попытка запустить не программу.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
Apache: Invalid command — не включён модуль Apache не запускается: директива требует модуль, который не подключён. Как найти нужный модуль и включить.
Argument list too long в службе или скрипте Список аргументов слишком длинный: подстановка имён файлов дала тысячи аргументов. Как переписать вызов.

Источники

systemd.exec(5)
Окружение процесса службы и переменная PATH по умолчанию. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на скрипте с вызовом отсутствующей команды и на службе с node из nvm. собственная проверка, systemd 255
сверено 15 сентября 2026