Systemd-unit — это конфигурационный файл, описывающий ресурс, которым управляет systemd: службу, сокет, устройство, точку монтирования, таймер или группу других unit-ов. Systemd — инициализационная система Linux, заменившая SysV init в большинстве современных дистрибутивов. Каждый unit имеет тип, определяющий его поведение, и набор директив, управляющих жизненным циклом.
Как работает systemd-unit
Unit-файлы хранятся в нескольких директориях: системные — в /lib/systemd/system/ (поставляются пакетами), пользовательские переопределения — в /etc/systemd/system/. Файлы из /etc/ имеют приоритет и позволяют изменять поведение системных unit-ов без правки оригиналов.
Структура unit-файла состоит из секций:
- [Unit] — описание и зависимости (After=, Requires=, Wants=)
- [Service] — параметры службы: ExecStart, Restart, User, WorkingDirectory
- [Install] — как unit включается в цель (WantedBy=multi-user.target)
Пример простого unit-файла для веб-приложения:
[Unit]
Description=My Web App
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.targetПосле создания файла нужно выполнить systemctl daemon-reload, затем systemctl enable --now myapp.service.
История
Systemd был разработан Леннартом Пёттерингом и впервые выпущен в 2010 году. К 2015 году большинство крупных дистрибутивов — Fedora, Debian, Ubuntu, Arch Linux — перешли на systemd. Переход сопровождался дискуссиями в сообществе: критики указывали на нарушение принципа UNIX «одна программа — одна задача», сторонники — на значительное ускорение загрузки и удобство управления. Сегодня systemd де-факто стандарт для серверных Linux-дистрибутивов.
Типы unit-ов
Systemd поддерживает несколько типов:
- .service — системные службы (Nginx, MySQL, приложения)
- .timer — аналог cron, запускает .service по расписанию
- .socket — socket activation: служба запускается при первом подключении
- .mount и .automount — точки монтирования файловых систем
- .target — группы unit-ов (аналог runlevel в SysV)
На что обращать внимание
При создании unit-ов важно правильно указывать зависимости. After= определяет порядок запуска, Requires= — жёсткую зависимость (если зависимость не запустилась — unit тоже не стартует), Wants= — мягкую. Для Docker-сервисов unit должен иметь After=docker.service Requires=docker.service.
Параметр Restart=always с RestartSec=5 обеспечивает автоматический перезапуск при падении — важно для продакшн-служб. Логи службы доступны через journalctl: journalctl -u myapp.service -f. Для мониторинга состояния служб можно использовать systemctl list-units --state=failed — покажет все упавшие unit-ы.
Unit-файлы можно переопределять без редактирования оригиналов: systemctl edit nginx.service создаёт override-файл в /etc/systemd/system/nginx.service.d/override.conf. Это удобно для добавления переменных окружения или изменения таймаутов без риска потерять изменения при обновлении пакета. Ansible и другие инструменты автоматизации умеют создавать unit-файлы как часть деплоя.