systemd — это подсистема инициализации и менеджер служб в Linux, пришедший на смену SysVinit. Она не просто запускает сервисы, а формирует целую экосистему управления системой.
- Параллельный запуск служб. Systemd умеет запускать независимые сервисы одновременно, а не строго по очереди. За счёт этого заметно сокращается время загрузки системы — в типичных десктопных дистрибутивах это хорошо заметно.
- Чёткие зависимости и транзакции. Состояние сервисов описывается в юнит‑файлах (`.service`, `.socket`, `.mount` и т. д.), где явно задаются зависимости (`After`, `Wants`, `Requires`). Systemd строит граф зависимостей и выполняет запуск/остановку транзакционно: если что‑то пошло не так, часть изменений можно откатить.
- Интеграция с cgroups. Каждый юнит автоматически привязывается к отдельной группе в cgroups. Это даёт простой и надёжный способ ограничивать ресурсы (CPU, память, диск) и точно отслеживать все процессы сервиса, без необходимости вручную управлять PID‑файлами и «ветвлением» демонов.
- Гибкие триггеры запуска. Службы можно активировать не только при загрузке, но и по событию: по сокету (`systemd.socket`), таймеру (`systemd.timer`), устройству (udev + `.device`) или даже по пути (`systemd.path`). Это позволяет реализовать паттерн «запуска по требованию» и экономить ресурсы.
- Единое управление жизненным циклом. Systemd управляет не только демонами, но и точками монтирования (`systemd.mount`), автомонтированием (`systemd.automount`), сетевыми интерфейсами (`systemd-networkd`), DNS (`systemd-resolved`), журналами (`systemd-journald`) и пользовательскими сессиями (`systemd-logind`). Это снижает фрагментацию инструментов и делает конфигурацию более предсказуемой.
- Удобные инструменты диагностики. Команды вроде `systemd-analyze` показывают, сколько времени заняли отдельные шаги загрузки, строят графики и даже оценивают безопасность конфигурации (`systemd-analyze security`). `journalctl` даёт единый интерфейс к логам со структурированными метаданными (источник, приоритет, юнит и т. п.).
- Богатые возможности изоляции и безопасности. В юнит‑файлах можно прямо указать параметры безопасности: `ProtectSystem`, `PrivateTmp`, `NoNewPrivileges`, `RestrictAddressFamilies` и другие. Это позволяет быстро и декларативно ограничивать привилегии служб, снижая риски при компрометации.
- Стандартизация между дистрибутивами. Благодаря тому, что systemd стала стандартом де‑факто в большинстве популярных дистрибутивов (Fedora, RHEL, Ubuntu, Debian и др.), скрипты и конфигурации оказываются более переносимыми, а документация и опыт администрирования — более универсальными.
- Высокая сложность и «монолитность». Systemd объединяет множество функций в одном проекте: от менеджера служб до сетевого стека и DNS‑резолвера. Из‑за этого порог входа для новичков выше, а отладка может быть сложнее: проблема в одном компоненте может влиять на другие.
- Отход от «Unix‑философии». Традиционный подход предполагает «одна программа — одна задача». Systemd же берёт на себя сразу много ролей, что вызывает критику у сторонников минимализма и модульности.
- Проблемы переносимости. Systemd тесно завязана на Linux‑специфичные механизмы (cgroups, D‑Bus и т. п.) и на glibc. Это затрудняет её использование в окружениях на базе других libc (например, musl) и на других Unix‑подобных системах.
- Бинарный формат журналов. `systemd-journald` хранит логи в бинарном формате. Хотя `journalctl` удобен, для интеграции с классическими инструментами (grep, awk, старые SIEM‑системы) это может быть неудобным, а восстановление данных при повреждении журнала — сложнее, чем с текстовыми логами.
- Единая точка отказа. Поскольку systemd (процесс с PID 1) управляет критически важными подсистемами, серьёзные сбои или ошибки конфигурации могут сильнее влиять на стабильность системы.
- Избыточность для простых и встраиваемых сценариев. В минималистичных или контейнеризированных средах (а также в некоторых серверных конфигурациях) многие функции systemd не нужны, а её размер и зависимости оказываются избыточными. Поэтому существуют дистрибутивы и варианты окружений без systemd (например, на базе OpenRC, runit, s6).
- Спорные компоненты и поведение по умолчанию. Некоторые части systemd вызывают дискуссии: например, `systemd-resolved` с его автоконфигурацией DNS или `systemd-boot`, который поддерживает только EFI. Администраторам, привыкшим к классическим инструментам (grub, bind, unbound, rsyslog), приходится осваивать новые подходы.
- Обратная совместимость и миграция. Несмотря на поддержку скриптов SysV, переход на systemd‑юниты не всегда тривиален: старые init‑скрипты могут полагаться на неявные зависимости и порядок запуска, который в systemd нужно прописывать явно.
---
Чтобы показать, насколько декларативно всё устроено, вот минимальный пример юнит‑файла:
```ini
[Unit]
Description=Простой сервис
After=network.target
[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
PrivateTmp=yes
ProtectSystem=full
[Install]
WantedBy=multi-user.target
```
Здесь сразу заданы: описание, зависимость от сети, автоматический перезапуск, изоляция `/tmp` и защита системных каталогов — всё в одном файле без внешних скриптов.