Почему после перезагрузки VPS не работает сайт: настройка systemd

После перезагрузки VPS сайт часто не открывается потому, что веб-сервер, приложение или база данных не запустились автоматически. Systemd решает эту задачу: он описывает сервис в отдельном юните, запускает его при загрузке Linux и показывает причину сбоя в журнале. В статье разберём настройку автозапуска для сайта и почты, проверку зависимостей, команды диагностики и ошибки, из-за которых сервис продолжает требовать ручного старта.

Почему сайт не поднимается после перезагрузки VPS?

Перезагрузка останавливает все процессы, которые работали в оперативной памяти. После включения сервер запускает только те службы, для которых настроен автоматический старт. Если приложение запускали вручную командой вроде «npm start», «python app.py» или через оболочку администратора, после reboot такой процесс исчезнет.

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

Сначала войдите на VPS с правами администратора и посмотрите состояние основных служб. Название зависит от установленного программного обеспечения:

• systemctl status nginx проверяет веб-сервер;

• systemctl status apache2 проверяет Apache;

• systemctl status postgresql или systemctl status mariadb проверяет базу данных;

• systemctl list-units --failed показывает службы, которые завершились с ошибкой.

Статус «failed» уже полезнее, чем сообщение браузера «сайт недоступен». В нём видны последние строки журнала и команда, которой systemd запускал службу.

Как включить автозапуск готового сервиса?

Если веб-сервер или база данных уже установлены как системные службы, отдельный юнит создавать не нужно. Для автозапуска применяют команду systemctl enable. Например, для Nginx последовательность выглядит так:

1. sudo systemctl enable nginx добавляет службу в загрузку;

2. sudo systemctl start nginx запускает её прямо сейчас;

3. sudo systemctl is-enabled nginx проверяет, включён ли автозапуск;

4. sudo systemctl is-active nginx показывает, работает ли процесс.

После изменения конфигурации веб-сервера сначала проверьте её отдельной командой, например nginx -t, и только потом выполняйте systemctl restart nginx. Ошибка в конфигурации остановит перезапуск, а сайт останется недоступным.

Для базы данных порядок похожий. Сначала включите службу, затем запустите её и проверьте статус. При этом название юнита нужно брать из системы: на одном VPS это mariadb, на другом postgresql. Нельзя подставлять имя по памяти, если пакет устанавливался нестандартно.

Как создать юнит systemd для приложения сайта?

Собственный юнит нужен приложению, которого нет среди стандартных служб Linux. Файл обычно размещают в каталоге /etc/systemd/system/. Например, для приложения с отдельным пользователем создайте файл myapp.service:

[Unit]
Description=Web application
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
Type=simple
User=myapp
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/python3 /var/www/myapp/app.py
Restart=on-failure
RestartSec=5
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

Этот пример показывает логику, а не универсальную готовую конфигурацию. Пути, имя пользователя и команду запуска нужно заменить на те, которые использует конкретное приложение. Узнать полный путь к интерпретатору или бинарному файлу можно командой which. Запуск через относительный путь часто ломается после перезагрузки, поэтому в ExecStart лучше указывать полный путь.

Параметр After= задаёт порядок запуска. Он говорит systemd подождать запуска сети и указанной базы, но сам по себе не гарантирует, что база успешно работает. Параметр Restart=on-failure перезапускает приложение после аварийного завершения. Значение RestartSec=5 задаёт паузу перед повторным запуском.

После сохранения файла перечитайте конфигурацию systemd и включите юнит:

1. sudo systemctl daemon-reload перечитывает новые и изменённые файлы;

2. sudo systemctl enable myapp.service добавляет приложение в автозапуск;

3. sudo systemctl start myapp.service запускает его без перезагрузки;

4. sudo systemctl status myapp.service показывает результат.

Команда enable не запускает сервис сразу. Это частая причина, по которой администратор меняет юнит, проверяет его статус и видит состояние «inactive». Для текущего запуска нужны отдельные команды start или restart.

Как настроить запуск почты и зависимых служб?

Почтовый сервер тоже должен быть зарегистрирован как служба systemd. Если его запускает внешний скрипт из домашнего каталога администратора, после перезагрузки он может не найти рабочую директорию, переменные окружения или права доступа. Для почты проверьте имя службы, её статус и журнал, а затем выполните systemctl enable.

Почтовая система часто зависит от сети, DNS, базы данных или локального хранилища. В юните приложения можно указать требуемый порядок, но сначала проверьте сами зависимости. Например, команда systemctl is-active postfix покажет состояние Postfix, если именно он установлен на сервере. Для другого почтового сервера имя будет иным.

Если служба стартует слишком рано, одного параметра After=network-online.target бывает недостаточно: нужный сетевой менеджер должен сообщать systemd, что сеть готова. Диагностика начинается с журнала конкретной службы, а не с повторного перезапуска всего VPS.

Как найти причину сбоя в журнале systemd?

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

• sudo journalctl -u myapp.service -n 100 --no-pager выводит последние 100 строк;

• sudo journalctl -u myapp.service -b показывает сообщения с текущей загрузки;

• sudo journalctl -u myapp.service -f следит за новыми строками в реальном времени;

• sudo systemctl cat myapp.service показывает фактический файл юнита.

Сообщение «No such file or directory» обычно указывает на неверный путь в ExecStart или WorkingDirectory. Ошибка «Permission denied» связана с пользователем службы, владельцем каталога или правами на файл. Сообщение о занятом порте означает, что другой процесс уже слушает нужный адрес; это проверяют командой ss -ltnp.

Проверяйте приложение напрямую от того же пользователя, который указан в User=. Команда, работающая от root, может обращаться к файлам и переменным, недоступным обычному пользователю. Такой тест быстро отделяет проблему systemd от ошибки самого приложения.

После исправлений выполните daemon-reload, затем restart и снова откройте журнал. Когда сайт начнёт запускаться, полезно добавить внешний контроль доступности VPS: отдельный материал о таком подходе описывает мониторинг VPS в Telegram с Uptime Kuma.

Какие ошибки мешают автозапуску?

• Файл юнита изменили, но не выполнили systemctl daemon-reload. Systemd продолжает использовать старую конфигурацию.

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

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

• Включили enable, но не выполнили start. Автозапуск будет работать при следующей загрузке, однако сейчас сервис останется остановленным.

• Добавили After=, но забыли проверить зависимую службу. Правильный порядок не исправит базу данных, которая завершается с ошибкой.

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

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