Написание unit-файла сервиса

У unit-файла три секции. Знание того, какой ключ в какой секции, устраняет большую часть путаницы. Помести файл в /etc/systemd/system/myapp.service:

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

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/server.py
Restart=on-failure
User=myapp
WorkingDirectory=/opt/myapp

[Install]
WantedBy=multi-user.target

[Unit] содержит метаданные и объявления зависимостей — всё, что верно независимо от типа юнита. [Service] содержит конфигурацию процесса: как запускать, от какого пользователя, поведение при перезапуске. [Install] содержит подключение для systemctl enable — какой target должен подтягивать этот сервис при включении.

Type= говорит systemd, как твой процесс сигнализирует о готовности. Ошибка здесь вызывает скрытые баги — systemd может объявить сервис “active” до того, как он реально обслуживает запросы, или зависнуть в ожидании готовности.

# Современный foreground-демон (Node.js, Python uvicorn, Go http.ListenAndServe)
[Service]
Type=simple
ExecStart=/usr/bin/node /opt/app/index.js

# Legacy nginx с двойным fork
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStart=/usr/sbin/nginx

Если задать Type=forking для процесса, который не делает fork, systemd будет ждать завершения родителя — которое никогда не наступит — и через 90 секунд пометит сервис как failed.

Restart= управляет тем, что происходит при неожиданном завершении процесса. Это одна из важнейших директив — разница между “разбудили в 3 ночи” и “сервис восстановился сам”:

[Service]
Restart=on-failure
RestartSec=5s          # Ждать 5 секунд перед перезапуском (избегает тесных петель)
StartLimitIntervalSec=60s  # Окно для подсчёта попыток перезапуска
StartLimitBurst=3      # Если перезапустился 3 раза за 60с — сдаться и войти в failed

Без RestartSec падающий сервис перезапускается немедленно и может спамить логи или нагружать CPU. Пара StartLimitBurst / StartLimitIntervalSec предотвращает бесконечные перезапуски при жёсткой ошибке конфигурации.

User=, Group= и WorkingDirectory= обязательны для production-сервисов. Запуск от root — угроза безопасности: скомпрометированный процесс получает все ключи от замка:

[Service]
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
RuntimeDirectory=myapp        # Создаёт /run/myapp с владельцем User= при старте
StateDirectory=myapp          # Создаёт /var/lib/myapp с владельцем User= при старте
LogsDirectory=myapp           # Создаёт /var/log/myapp с владельцем User= при старте

RuntimeDirectory, StateDirectory и LogsDirectory — чистый способ systemd создавать и владеть директориями при старте сервиса. Никаких хаков с ExecStartPre=mkdir, директории создаются с правильными правами автоматически.

Пользователь myapp должен быть системным пользователем, созданным при деплое:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp

После написания или редактирования unit-файла нужно сказать systemd перечитать его через daemon-reload. systemd кешируем unit-файлы. Без daemon-reload он продолжит использовать старое определение, даже если перезапустить сервис:

# После создания или редактирования /etc/systemd/system/myapp.service
sudo systemctl daemon-reload

# Теперь новое определение активно — запустить или перезапустить
sudo systemctl enable --now myapp.service

# Убедиться, что работает как ожидается
systemctl status myapp.service

# Наблюдать живые логи для этого сервиса
journalctl -u myapp.service -f

Самый частый вопрос в поддержке: “Я обновил unit-файл, но ничего не изменилось.” В девяти случаях из десяти был пропущен daemon-reload.