Статус 203 у сервиса systemd — exec, который так и не запустился

Что на самом деле означает статус 203/EXEC?

Главное предложение: status=203/EXEC — это systemd сообщает, что execve твоей команды ExecStart провалился в момент запуска — твоего процесса никогда не существовало, поэтому логика, конфиг и код самого сервиса тут ещё ни при чём. На стенде одноразовый oneshot-юнит, по очереди носивший каждую неисправность, печатал один и тот же вердикт каждый раз:

$ systemctl show bench203.service -p ExecMainCode -p ExecMainStatus -p Result
ExecMainCode=1
ExecMainStatus=203
Result=exit-code

проверка: ExecMainCode=1 — это CLD_EXITED, а 203 — статус выхода семейства exec; тот же юнит после лечения читается как ExecMainStatus=0 и Result=success (квитанция ниже).

Три разные ошибки, один номер

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

Process: 703 ExecStart=/opt/bench203/no-such-binary (code=exited, status=203/EXEC)
Process: 778 ExecStart=/opt/bench203/worker.sh      (code=exited, status=203/EXEC)   # file exists, mode 0644
Process: 853 ExecStart=/opt/bench203/shebang.sh     (code=exited, status=203/EXEC)   # +x, interpreter missing

проверка: три запуска, три одинаковых хвоста status=203/EXEC — экран статуса показывает «что», никогда «который».

Народное лечение — переустановить программу или гонять юнит перезапусками по кругу. Петля перезапусков здесь и есть ложь: пациентом программа никогда не была. Вторая строка записи в журнале — та, что под Starting…, — и есть диагноз, и все три раза она разная:

bench203.service: Unable to locate executable '/opt/bench203/no-such-binary': No such file or directory
bench203.service: Unable to locate executable '/opt/bench203/worker.sh': Permission denied
bench203.service: Failed to execute /opt/bench203/shebang.sh: No such file or directory

проверка: скопировано дословно из journalctl -u bench203.service, по строке на неисправность, PIDs 703 / 778 / 853.

Какая из трёх твоя?

Читай вторую строку в два шага. Сначала фраза: Unable to locate executable говорит о твоём пути (сбой A или B); Failed to execute значит, что systemd прошёл твой файл и потерял нечто, что сам и называет, — интерпретатор в строке 1 (сбой C). Потом errno после двоеточия: No such file or directory против Permission denied разделяет A и B.

Формулировка сбоя B заслуживает отдельного предупреждения: Unable to locate executable … Permission denied обвиняет файл в несуществовании, пока файл лежит прямо там — 28 байт, режим 0644, никого не трогает. systemd файл нашёл; просто сказать этого в той фразе не может. Правда — в errno, а не в глаголе.

Как починить статус 203/EXEC?

Лечение на стенде — один chmod для формы B и честная строка 1 для формы C — без переустановок, без петли перезапусков:

sudo chmod 0755 /opt/bench203/worker.sh        # give back the exec bit
# and make line 1 of the script name a real interpreter:
#!/bin/bash
$ systemctl show bench203.service -p ExecMainStatus -p Result
ExecMainStatus=0
Result=success

проверка: журнал вылеченного запуска читается worker.sh[931]: worker ran → Deactivated successfully. → Finished bench203 fault shapes. — oneshot сделал своё дело и ушёл.

Сентябрьский сервис systemd не стартует: журнал уже назвал причину обещал то же самое для более тихой неудачи. 203 — тот же закон на самой громкой ноте: признание ложится в журнал ещё до того, как ты откроешь unit-файл.

Лечение, по порядку

• systemctl status <unit> -l — подтверди status=203/EXEC на строке Main PID
• journalctl -u <unit> --no-pager — прочитай вторую строку: Unable to locate (твой путь) или Failed to execute (интерпретатор)
• errno после двоеточия — No such file or directory или Permission denied
• ls -l на путь (биты x) · head -1 на скрипт (кто назван интерпретатором) · test -x на того интерпретатора
• почини единственное, systemctl start снова — show -p Result читает success

Три признания одним взглядом

что говорит журнал	чего не хватает	лечение
Unable to locate executable … No such file or directory	сам путь ExecStart	исправь путь — абсолютный, без опечаток
Unable to locate executable … Permission denied	бит исполнения	sudo chmod +x /path/to/script
Failed to execute … No such file or directory	интерпретатор из shebang	исправь строку 1 (#!/bin/bash) или поставь интерпретатор

«203 — это не твой сервис умирает, это systemd не может вручить ему ключи. Журнал каждый раз называет, какой именно ключ.»

чего стенд не покрыл

Замерено: три формы сбоя (нет пути, режим 0644, сломанный shebang) на одной свежей VM Arch, systemd 262 (262.1-1-arch), oneshot-юнит, с разницей в секунды, плюс вылеченный запуск. Не замерено: относительный путь ExecStart — systemd отвергает его ещё на разборе со своим собственным сообщением, не 203 (публичная документация); отказы SELinux/AppArmor — они всплывают с тем же errno Permission denied — проверь свой LSM, прежде чем винить бит; пути ExecStart в chroot. Одна машина, один build: переносимая часть — правило чтения; вердикт — твоя собственная строка журнала.

СТЕНД, ПРОВЕРЕННЫЙ ВРУЧНУЮ · systemd 262 (262.1-1-arch) · свежая VM Arch · последний тест 2026-11-11

Один номер, три двери — и журнал, который называет дверь каждый раз. Читай вторую строку, прежде чем что-то перезапускать. ■