Systemd — это одновременно надёжный союзник и источник самых неожиданных проблем на проде. Он умеет запускать, контролировать, логировать и перезапускать сервисы, управлять зависимостями, точками монтирования, сокетами, таймерами и многим другим. Но стоит выйти за рамки типовой конфигурации — и systemd способен повести себя совсем не так, как вы ожидали.
Systemd как DevOps-инструмент
Для большинства современных Linux-дистрибутивов systemd — уже не альтернатива, а стандарт. На наших VDS в Webhost1 он предустановлен в образах Ubuntu, Debian, AlmaLinux, CentOS, Fedora — и с ним связана вся автоматизация сервисов на уровне ОС. Мы используем systemd не только для запуска демонов, но и для healthcheck'ов, автоматических рестартов и запуска задач по расписанию без cron.
Юниты .service и .timer позволяют нам:
- запускать сервисы с учётом зависимостей (After=, Requires=);
- задавать политики перезапуска (Restart=on-failure, RestartSec=5);
- изолировать процессы (ProtectSystem=, ReadOnlyPaths=);
- управлять ресурсами через cgroups (CPUQuota=, MemoryMax=);
- логировать через journalctl без сторонних лог-агентов.
Это даёт контроль на уровне операционной системы, который невозможно получить средствами самого приложения или через сторонние супервизоры.
Когда всё ломается: кейсы из практики
Сервис не стартует после перезагрузки
Причина: забыли After=network-online.target, используем network.target, и сервис запускается раньше, чем поднимается интерфейс.
Решение: явно указать After=network-online.target и убедиться, что systemd-networkd-wait-online.service активен.
Systemd перезапускает сервис бесконечно, нагружая систему
Причина: Restart=always без ограничений. Падение за падением — и вот уже PID 1 крутит умирающий процесс в цикле.
Решение: добавить RestartSec=5 и перейти на on-failure. Это даст сервису шанс восстановиться, не создавая спираль деградации.
SLA рушится при high-load: systemd блокирует старт из-за зависимостей
Причина: сложная цепочка Requires= и After= вызывает задержку. Один сервис ждёт другой, тот — третий, а в итоге — таймаут.
Решение: выстраивать зависимости минимально необходимыми. Использовать Wants= для необязательных связей и следить за графом systemctl list-dependencies.
Когда systemd — зло?
Для опытных DevOps-инженеров systemd может стать врагом, если вы рассчитываете на прозрачную предсказуемость, но не изучили документацию. Особенно:
- при миграции со старых скриптов SystemV без учёта разницы в логике запуска;
- при использовании юнитов сторонних приложений, не адаптированных под вашу инфраструктуру;
- при отладке продакшн-проблем, когда journalctl ничего не показывает, а причина зарыта в ExecStartPre=.
Также systemd сложно контейнеризировать. Его работа в chroot-средах, контейнерах Docker или Kubernetes требует особой настройки и далеко не всегда оправдана.
Когда systemd — это выход
На выделенных серверах Webhost1 с десятками сервисов systemd становится незаменим. Он позволяет:
- упростить CI/CD: выкатка нового сервиса — это просто scp unit && daemon-reload && restart;
- контролировать аварийные перезапуски;
- отслеживать метрики запуска (systemd-analyze blame);
- задавать единые правила sandbox'а и безопасности;
- автоматизировать обновление конфигураций через ansible/puppet.
В связке с VDS на NVMe-дисках и CPU с частотой от 3.9 ГГц systemd показывает отличные времена старта, особенно при параллельной инициализации.
Вывод
Systemd не враг. Но он требует уважения. Это система с собственным видением и правилами. Она может быть строгой, но справедливой — особенно если ты знаешь, как с ней говорить.
Если вы хотите сервер, на котором systemd действительно работает, а не мешает, — выбирайте проверенную инфраструктуру. В Webhost1 мы поможем не только развернуть VPS, но и подготовить юниты, настроить мониторинг и автоматизацию.
И да, если вы устали от бесконечного tail -f, добро пожаловать в journalctl.