SystemdDoctor
служба не работает монтирование порядок запуска

Служба запускается раньше монтирования своих данных

systemd не догадывается, какие пути нужны службе. Если данные лежат на отдельном диске, службу нужно связать с его точкой монтирования явно. Иначе служба стартует раньше и падает на отсутствующих файлах — а после ручного перезапуска работает, что сильно запутывает разбор.

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

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

  1. Зависимость от точки монтирования не объявлена

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

  2. Зависимость указана на unit вручную и с ошибкой

    Имя unit монтирования выводится из пути по особым правилам. Написанное вручную имя легко ошибочно.

  3. Служба падает только при загрузке, а вручную работает

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

Диагностика

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

Объявленные зависимости от путей и порядок запуска.

systemctl show myapp.service -p RequiresMountsFor -p After

Верное имя unit монтирования для пути.

systemd-escape -p --suffix=mount /srv/data

Что было при загрузке: успел ли диск смонтироваться.

journalctl -u myapp.service -b --no-pager | head -20

Решение

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

1. Зависимость от точки монтирования не объявлена
Почему происходит
Служба стартует одновременно с монтированием. Кто успеет первым, зависит от скорости диска.
Как проверить
Посмотрите зависимости службы и точку монтирования данных. 
systemctl show myapp.service -p RequiresMountsFor -p After
findmnt -T /srv/data -o TARGET,SOURCE
Как исправить
Объявите нужные пути параметром зависимости от монтирования: systemd сам выведет нужные unit и порядок. 
[Unit]
RequiresMountsFor=/srv/data
2. Зависимость указана на unit вручную и с ошибкой
Почему происходит
Имя unit монтирования выводится из пути по особым правилам. Написанное вручную имя легко ошибочно.
Как проверить
Посмотрите верное имя unit для пути. 
systemd-escape -p --suffix=mount /srv/data
systemctl show myapp.service -p After
Как исправить
Используйте зависимость от пути вместо ручного имени unit: имя вычислит systemd. Так не получится ошибки при переносе.
3. Служба падает только при загрузке, а вручную работает
Почему происходит
Признак гонки: при ручном запуске диск уже смонтирован. Это сбивает с толку и заставляет искать причину не там.
Как проверить
Сравните поведение при загрузке и после неё. 
journalctl -u myapp.service -b --no-pager | head -20
systemctl status myapp.service --no-pager | head -6
Как исправить
Объявите зависимость от монтирования. Перезапуск при сбое с задержкой маскирует гонку, но не устраняет её.

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

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

systemd[1]: Started myapp.service - My application.
myapp[900]: fatal: open /srv/data/db.sqlite: no such file or directory
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Mounting /srv/data...

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

Источники

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