systemd на VPS: автозапуск приложений после перезагрузки

Запуск в screen — только для отладки. В production бот и API должны подниматься после ребута VPS. systemd — стандарт на Ubuntu и Debian.

Зачем systemd

systemd — init-система Linux: управляет сервисами, зависимостями, логами и перезагрузкой. Любой long-running процесс на VPS должен быть unit-файлом.

После apt upgrade и reboot сервер поднимает сеть, монтирует диски и стартует enabled-сервисы в правильном порядке (After=network.target).

Альтернативы (supervisor, PM2) добавляют слой; systemd уже есть и интегрирован с journald.

Type=notify поддерживают Gunicorn и некоторые daemons — systemd ждёт sd_notify READY=1 перед считанием сервиса active.

Логи journald ротируются автоматически; для compliance export в syslog-ng или Loki по мере требований.

Unit-файл

Создайте /etc/systemd/system/myapp.service:

[Unit]
Description=My API
After=network.target

[Service]
User=deploy
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/gunicorn app:app
Restart=always
RestartSec=5
EnvironmentFile=/etc/myapp/env

[Install]
WantedBy=multi-user.target

User= — не root. WorkingDirectory — cwd процесса. EnvironmentFile — секреты вне unit.

StandardOutput=journal и StandardError=journal отправляют stdout/stderr приложения в journalctl без отдельных log-файлов на диске.

ExecStartPre=/usr/bin/test -f /etc/myapp/env — fail fast если забыли секреты, вместо silent crash приложения.

Requires=postgresql.service в unit API — systemd не стартует app до готовности БД, снижает crash loop при boot order race.

enable и start

systemctl daemon-reload после изменения unit. systemctl enable --now myapp — старт сейчас и автозапуск при boot.

systemctl status myapp — active (running). systemctl stop/start/restart — управление без правки конфига.

После enable проверьте перезагрузку: reboot и убедитесь, что сервис поднялся без ручного вмешательства — это главный smoke test автозапуска на любом production VPS.

TimeoutStopSec=30 даёт процессу время graceful shutdown перед SIGKILL — важно для API с long requests.

ProtectSystem=strict и ReadWritePaths=/opt/myapp — hardening unit ограничивает filesystem write даже при RCE в app (Defense in depth).

Restart policies

Restart=always — перезапуск при любом exit. on-failure — только при ненулевом коде. RestartSec=5 — пауза между попытками.

StartLimitBurst и StartLimitIntervalSec — защита от restart loop при сломанном конфиге.

systemd-analyze blame показывает, что задерживает boot — лишние enabled services замедляют reboot после kernel patch.

CPUQuota=200% ограничивает runaway process двумя cores — предотвращает total VPS freeze от одного bug.

journalctl

journalctl -u myapp -f — live logs. journalctl -u myapp --since today — за сегодня.

Логи в journald переживают rotate лучше произвольных файлов; LogLevel в unit для verbose при отладке.

Drop-in override: systemctl edit myapp создаёт fragment без правки vendor unit — переживает package updates.

systemctl list-timers — visibility scheduled tasks рядом с services в одной operational model.

Несколько сервисов

API + worker + scheduler — три unit-файла. After=myapp.service в worker, если worker зависит от API.

systemd timer вместо cron для периодических задач — логи и failure handling в одной системе.

WantedBy=multi-user.target vs graphical.target — на headless VPS всегда multi-user.

Ошибки

• 203/EXEC — неверный путь ExecStart.
• Permission denied — User без прав на файлы.
• Забыли daemon-reload — старый unit в памяти.

systemctl cat myapp показывает итоговый unit с drop-in overrides.

Для отладки запускайте ExecStart команду вручную от того же User= в WorkingDirectory — так быстрее находятся ошибки пути и прав до оформления сервиса.

Сocкet activation (socket units) — advanced pattern для on-demand сервисов; для API чаще простой always-on unit.

Частые вопросы