🛠️ Почему systemd-сервис не стартует после перезагрузки Скрипт запускается вручную:

cd /opt/report-app APP_ENV=prod ./venv/bin/python app.py

Но после перезагрузки сервис не поднимается.

Разберём не общий список причин, а один unit-файл:

[Unit] Description=Report application After=network.target postgresql.service [Service] User=report WorkingDirectory=/opt/report-app EnvironmentFile=/etc/report-app/report-app.env ExecStart=/opt/report-app/venv/bin/python app.py Restart=on-failure [Install] WantedBy=multi-user.target

На вид всё логично. Но ручной запуск и запуск через systemd выполняются в разных условиях.

1. Unit включён в автозапуск?

Наличие [Install] и WantedBy=multi-user.target ещё не означает, что unit включён. Эта секция описывает связи, которые создаются при включении службы, но сама их не создаёт.

2. Доступен ли рабочий каталог?

WorkingDirectory=/opt/report-app задаёт каталог процесса. Аргумент app.py в ExecStart= разрешается относительно него.

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

3. Есть ли доступ у пользователя report?

Ручную проверку администратор выполняет под своей учётной записью, а unit запускает процесс как report.

Нужно проверить доступ к каталогу, app.py, интерпретатору, конфигурации и другим необходимым ресурсам. Если Group= не указан, используется основная группа пользователя.

4. Загружено ли нужное окружение?

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

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

5. Запускается ли зависимость и готова ли она?

After=postgresql.service задаёт порядок, только если оба unit участвуют в запуске. Оно не запускает PostgreSQL само и не гарантирует, что база уже принимает подключения.

Даже сочетание с Wants= или Requires= описывает зависимости между unit, но не прикладную готовность базы. Для приложения могут потребоваться повторные подключения или другой предусмотренный механизм обработки временной недоступности.

После этого сравните состояние unit и журнал именно той загрузки, в которой произошёл сбой.

Типичная ошибка — менять сразу пользователя, пути, зависимости и окружение. Сервис может запуститься случайно, но настоящая причина останется неизвестной.

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

Сохраните сценарий для диагностики служб после перезагрузки.

🔹🔹🔹🔹