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

No such file or directory в журнале службы

Сообщение No such file or directory — отказ ядра с номером 2 (ENOENT). Файла нет по указанному пути в тот момент, когда служба к нему обратилась. Тонкость в том, что «нет» может означать «ещё нет», «не в этом пространстве имён» или «ссылка ведёт в пустоту».

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

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

  1. Пути действительно нет

    Опечатка, файл удалён, каталог не создан при установке, программа ищет файл в другом месте, чем вы думаете.

  2. Файл появляется позже запуска службы

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

  3. Путь скрыт параметрами изоляции

    При PrivateTmp=yes служба видит свой собственный /tmp, а не общий: файл, положенный туда вручную, для неё не существует. Похоже ведут себя ProtectHome= и InaccessiblePaths=.

  4. Символическая ссылка ведёт в никуда

    Ссылка существует, а её цель — нет. Обращение к такой ссылке даёт ровно это сообщение, и глазами в выводе ls проблему легко пропустить.

  5. Отсутствует интерпретатор или библиотека, а не сам файл

    При запуске скрипта сообщение может относиться к интерпретатору из строки #!, а при запуске программы — к недостающей библиотеке. Файл, на который вы смотрите, при этом на месте.

Диагностика

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

Даёт точный путь: дальше разбор идёт по нему, а не по догадкам.

journalctl -u myapp.service -n 40 --no-pager | grep -i -E "no such|ENOENT"

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

namei -l /путь/из/сообщения

Параметры, из-за которых служба может не видеть существующий файл.

systemctl show myapp.service | grep -E "PrivateTmp|ProtectHome|RootDirectory"

Решение

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

1. Пути действительно нет
Почему происходит
Опечатка, файл удалён, каталог не создан при установке, программа ищет файл в другом месте, чем вы думаете.
Как проверить
Найдите точный путь из сообщения и проверьте его. 
journalctl -u myapp.service -n 40 --no-pager | grep -i "no such"
ls -l /путь/из/сообщения
Как исправить
Создайте файл или каталог, либо исправьте путь в настройках. Для каталогов службы удобнее StateDirectory= — systemd создаст их сам с нужными правами.
2. Файл появляется позже запуска службы
Почему происходит
Служба стартует раньше монтирования раздела или раньше службы, которая создаёт файл. При ручном перезапуске всё работает, после перезагрузки — нет.
Как проверить
Сравните порядок запуска и время появления пути. 
systemctl show myapp.service -p After -p Requires
findmnt -T /data
Как исправить
Добавьте RequiresMountsFor=/путь для каталога на отдельном разделе или зависимость от службы, создающей файл. 
[Unit]
RequiresMountsFor=/data
3. Путь скрыт параметрами изоляции
Почему происходит
При PrivateTmp=yes служба видит свой собственный /tmp, а не общий: файл, положенный туда вручную, для неё не существует. Похоже ведут себя ProtectHome= и InaccessiblePaths=.
Как проверить
Посмотрите параметры изоляции и попробуйте заглянуть внутрь пространства имён службы. 
systemctl show myapp.service | grep -E "PrivateTmp|ProtectHome|Inaccessible"
sudo ls /tmp/systemd-private-*-myapp.service-*/tmp 2>/dev/null | head
Как исправить
Передавайте файлы через каталоги службы (StateDirectory=, RuntimeDirectory=) или явно разрешайте путь в BindPaths=. Общий /tmp для обмена данными — плохая практика и без изоляции.
4. Символическая ссылка ведёт в никуда
Почему происходит
Ссылка существует, а её цель — нет. Обращение к такой ссылке даёт ровно это сообщение, и глазами в выводе ls проблему легко пропустить.
Как проверить
Проверьте, куда ведёт ссылка. 
ls -l /путь/из/сообщения && readlink -f /путь/из/сообщения
Как исправить
Исправьте или удалите битую ссылку. Команда readlink -f печатает конечный путь, и он же будет пустым, если цепочка обрывается.
5. Отсутствует интерпретатор или библиотека, а не сам файл
Почему происходит
При запуске скрипта сообщение может относиться к интерпретатору из строки #!, а при запуске программы — к недостающей библиотеке. Файл, на который вы смотрите, при этом на месте.
Как проверить
Посмотрите первую строку скрипта и список библиотек. 
head -1 /opt/myapp/run.sh
ldd /usr/local/bin/myapp | grep "not found"
Как исправить
Исправьте строку #! или установите недостающую библиотеку. Это же частая причина кода 203/EXEC.

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

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

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-15 12:11:44 MSK; 1s ago
    Process: 5510 ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.yml (code=exited, status=1/FAILURE)

myapp[5510]: fatal: open /etc/myapp/config.yml: no such file or directory
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

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

  • status=203/EXEC в systemd Код 203/EXEC означает, что systemd не смог выполнить программу из ExecStart=. Разбор причин: путь, права, интерпретатор, синтаксис оболочки.
  • status=200/CHDIR в systemd Код 200/CHDIR означает, что systemd не смог перейти в каталог из WorkingDirectory= до запуска программы. Причины и решение.
  • Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
  • status=226/NAMESPACE в systemd Код 226/NAMESPACE: не удалось настроить пространства имён монтирования, UTS или IPC. Частая причина — путь в ReadOnlyPaths= или ProtectHome=.
  • Exec format error при запуске службы Ошибка формата исполняемого файла: не та архитектура, нет строки #!, повреждённый файл или попытка запустить не программу.
  • Not a directory в журнале службы Ошибка 20: часть пути оказалась файлом, а не каталогом. Разбор для путей в unit-файле и в настройках.
  • Too many levels of symbolic links Ошибка 40: цикл символических ссылок или слишком глубокая цепочка.
  • status=209/STDOUT в systemd Код 209/STDOUT: systemd не смог настроить стандартный вывод службы. Чаще всего виноват путь в StandardOutput=append: или file:.

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

Источники

  • systemd.exec(5)
    PrivateTmp=, ProtectHome=, BindPaths= и видимость путей внутри службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на отсутствующем файле настроек, на битой ссылке и на PrivateTmp=yes.     собственная проверка, systemd 255
    сверено 15 сентября 2026