Свой systemd unit‑файл с нуля: от минимального скелета до production‑конфига

В сфере искусственного интеллекта произошло заметное событие. badcasedaily1 6 минут назад Свой systemd unit‑файл с нуля: от минимального скелета до production‑конфига Средний 12 мин 55 Блог компании OTUS Linux * Программирование * DevOps * Туториал Когда нужно запустить свой сервис на Linux‑хосте, выбор небольшой: либо systemd unit‑файл, либо что‑то из эры до systemd — init‑скрипт, supervisord, screen, nohup. На современных дистрибутивах (Ubuntu 22. 04+, Debian 12, RHEL 9+, Amazon Linux 2023) systemd — стандарт по умолчанию, и причины для других вариантов остаются только в legacy‑проектах.

Сам unit‑файл выглядит просто: пара десятков строк в формате INI с тремя секциями. Но за этой простотой прячется приличное количество нюансов — какой Type= выбрать, как настроить рестарт, чтобы он не превратился в спам, какой набор security‑параметров включить, чтобы сервис не имел доступа в /etc и /home без необходимости, и как корректно интегрировать с journald. К весне 2026 актуальная версия systemd — 258 (релиз март 2026), но базовые конструкции для unit‑файлов стабильны последние лет десять и работают одинаково на всех современных дистрибутивах.

Технические детали

В статье разбор того, как написать unit‑файл для своего сервиса с нуля, и какие параметры стоит выставлять не как «скопировал с примера», а с пониманием. Минимальный unit‑файлДопустим, у вас есть Spring Boot приложение, упакованное в jar, которое нужно запускать как systemd‑сервис. Создаём файл /etc/systemd/system/api.

service: Description=API service After=network. target Type=simple User=api WorkingDirectory=/opt/api ExecStart=/usr/lib/jvm/java-25/bin/java -jar /opt/api/app. jar Restart=on-failure WantedBy=multi-user.

targetКоманды для активации и проверки:sudo systemctl daemon-reload # после изменения unit-файла sudo systemctl enable --now api sudo systemctl status api sudo journalctl -u api -fЭто минимально работающий вариант — сервис запускается при старте системы, перезапускается при падении, логи идут в journald. Но в рабочей конфигурации к этому скелету добавляется ещё пять‑семь блоков, без которых сервис либо работает не так, как ожидалось, либо открывает дыры в безопасности. Type=: выбор модели запускаsystemd различает несколько типов сервисов, и от выбора зависит, как systemd понимает, что сервис стартанул и продолжает работать.

Основные варианты:Type=simple (дефолт) — самый простой и в большинстве случаев правильный. systemd считает сервис стартовавшим сразу после fork() и запуска ExecStart, не дожидаясь никакого сигнала «я готов». Подходит для приложений, которые становятся полезными сразу после запуска бинаря: большинство Spring Boot и Node.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.