Управление systemd‑сервисами в Linux

Быстрые ссылки

• Проверить, используется ли systemd
• Проанализировать процесс загрузки
• Просмотреть единицы (units)
• Управлять сервисами
• Журнал и отладка

Важно: в дистрибутивах на базе Debian/Ubuntu команды, изменяющие систему, обычно запускают с sudo. В других дистрибутивах сначала переключитесь на root через su.

Что такое systemd — коротко

Systemd — это подсистема и менеджер инициализации и сервисов. Он управляет процессами, точками монтирования, сокетами и журналом. Термин «юнит» (unit) в systemd обозначает объект конфигурации (service, mount, socket и т. д.).

Определение: юнит — конфигурация для ресурса ОС, которую systemd может запускать, останавливать и отслеживать.

Проверка: используется ли systemd

Откройте терминал и выполните:

systemd –version

Если systemd установлен, команда выведет его версию. В дистрибутивах без systemd команда не найдётся.

Анализ процесса загрузки

systemd-analyze показывает время загрузки и узкие места. Полезно при оптимизации старта сервера или рабочего компьютера.

Просмотреть общую информацию о загрузке:

systemd-analyze

Посмотреть, какие юниты добавили больше всего времени:

systemd-analyze blame

Результат сортируется по времени. Это помогает найти «тяжёлые» сервисы.

Совет: если boot time высокое, проверьте failed юниты и сервисы с долгим ожиданием сокетов.

Виды юнитов и просмотр единиц

Типы юнитов: .service — сервисы, .mount — точки монтирования, .socket — сокеты, .device — устройства, .target — цели (аналог runlevel). Вы управляете всеми этими типами через systemctl.

Показать все файлы юнитов:

systemctl list-unit-files

Показать все активные юниты:

systemctl list-units

Показать только упавшие юниты:

systemctl –failed

Пояснение: «файл юнита» — это конфигурация, доступная в /lib/systemd/system или /etc/systemd/system; «юнит» — запущенный/зарегистрированный экземпляр в текущем рантайме.

Управление сервисами (start/stop/restart/reload/status)

Частые команды для сервисов:

systemctl start name.service systemctl stop name.service systemctl restart name.service systemctl reload name.service systemctl status name.service

Команда status печатает лог и статус в терминал. Остальные команды выполняются «тихо» — они не возвращают журнал в поток по умолчанию.

Чтобы увидеть список включённых и выключенных сервисов:

systemctl list-unit-files –type=service

Автозапуск управления:

systemctl enable name.service systemctl disable name.service

Если нужно полностью запретить запуск сервиса (в т.ч. когда другой юнит пытается его активировать), используйте mask/unmask:

systemctl mask name.service systemctl unmask name.service

Совет: mask полезен при временной блокировке проблемного сервиса на продакшне.

Журнал: journalctl

Systemd использует собственный журнал systemd-journald. Чтобы читать логи:

journalctl -u name.service

Просмотреть логи текущей загрузки:

journalctl -b

Следить в реальном времени:

journalctl -f -u name.service

По умолчанию журнал хранится в бинарном формате; для экспорта в текст используйте опции или journalctl –no-pager.

Примеры файла юнита (unit file)

Минимальный example.service:

[Unit] Description=Пример сервиса After=network.target

[Service] Type=simple ExecStart=/usr/bin/example –serve Restart=on-failure

[Install] WantedBy=multi-user.target

Сохраните как /etc/systemd/system/example.service, затем:

systemctl daemon-reload systemctl enable –now example.service

Пояснение: daemon-reload сообщает systemd перечитать файлы юнитов. enable –now включает автозапуск и сразу стартует сервис.

Отладка распространённых проблем

• Сервис не запускается: проверьте journalctl -u и status.
• service зависает в ожидании сокета: проверьте .socket и зависимые юниты.
• Изменения в юните игнорируются: не забудьте daemon-reload.
• Сервис запускается вручную, но не при загрузке: проверьте WantedBy и enable.

Критерии приёмки для юнита:

• Юнит запускается без ошибок (systemctl start).
• Юнит успешно перезапускается (systemctl restart).
• Логи доступны через journalctl -u.
• Юнит правильно включён/отключён (enable/disable).

Ролевые чеклисты

Администратор:

• Проверить версию systemd
• Просмотреть failed юниты
• Проверить автозапуск ключевых сервисов
• Анализировать загрузку systemd-analyze

Разработчик приложения:

• Написать unit файл с понятным Description
• Указать корректный Type и Restart
• Писать логи в stdout/stderr для journal
• Проверить зависимости (After, Wants)

Оператор/DevOps:

• Автоматизировать daemon-reload при деплое
• Создать systemd-timers для задач, если нужно
• Настроить лимиты и cgroup-параметры в юните

Альтернативы и случаи, когда systemd не подходит

Альтернативы: SysVinit, OpenRC, runit, s6. Они проще по дизайну и могут использоваться в контейнерах или лёгких системах. Если вы строите минималистичную систему или контейнеры с узкими требованиями к init‑системе, systemd может быть избыточен.

Когда systemd не подходит:

• Встраиваемые системы с жесткими требованиями по ресурсам.
• Специальные контейнеры, где требуется минимальный PID1.

Безопасность и жесткие настройки

• Ограни́чьте права сервиса: используйте User= и Group= в [Service].
• Включите PrivateTmp=yes, ProtectSystem=full, NoNewPrivileges=yes для сокращения влияния процесса на систему.
• Для критичных сервисов задавайте пределы через LimitNOFILE и CapabilityBoundingSet.

Пример безопасного фрагмента в юните:

[Service] User=svc_user ProtectSystem=full PrivateTmp=yes NoNewPrivileges=yes

Маленькая методология — как вводить новый сервис в прод

1. Разработать и протестировать unit локально.
2. Проверить логи и поведение через journalctl и status.
3. Добавить в систему на staging, выполнить daemon-reload.
4. Включить enable и monitor метрики/логи 24–48 часов.
5. При откате — mask сервис и восстановить предыдущую версию.

Мини‑playbook для деплоя сервиса:

• Скопировать example.service в /etc/systemd/system/
• systemctl daemon-reload
• systemctl enable –now example.service
• Проверить: systemctl status example.service; journalctl -u example.service -n 200

Тесты и критерии приёмки

Тестовые шаги:

• Запуск: systemctl start, проверить exit code.
• Перезапуск: systemctl restart, убедиться, что сервис поднимается.
• Проверка логов: journalctl -u, отсутствуют ошибки CRITICAL.
• Падение сервиса: сымитировать падение и убедиться, что Restart=on-failure срабатывает.

Критерии приёмки:

• Сервис работает без критических ошибок 15 минут после запуска.
• Логи показывают вход в работу и отсутствие неожиданных перезапусков.

Советы по миграции с других init-систем

• Перепишите init-скрипты в unit файлы; простые скрипты обычно конвертируются вручную.
• Убедитесь, что зависимости и порядок запуска (After, Wants) правильно заданы.
• Тестируйте в контрольной среде перед переводом продакшна.

Быстрая шпаргалка — набор команд

• Проверить версию: > systemd –version
• Общая информация о загрузке: > systemd-analyze
• Топ «тяжёлых» юнитов: > systemd-analyze blame
• Просмотреть все юниты: > systemctl list-units
• Просмотреть файлы юнитов: > systemctl list-unit-files
• Старт/стоп/рестарт: > systemctl start|stop|restart name.service
• Включить автозапуск: > systemctl enable name.service
• Маскировать: > systemctl mask name.service
• Журнал сервиса: > journalctl -u name.service

Когда что-то идёт не так — краткий инцидент‑план

1. Проверить статус: systemctl status name.service.
2. Просмотреть последние логи: journalctl -u name.service -n 200.
3. Временно маскировать проблемный сервис: systemctl mask name.service.
4. Перевести трафик/нагрузку на запасной узел (если есть).
5. Откатить изменения конфигурации или юнита.
6. После исправления: systemctl unmask, daemon-reload, systemctl restart.

Короткая глоссарий (1 строка на термин)

• unit: конфигурационный объект systemd.
• service: юнит, управляющий службой/демоном.
• target: логическая цель загрузки, аналог runlevel.
• journal: централизованный лог systemd.
• mask: запрет на запуск юнита.

Дополнительные ресурсы

• Вики Arch Linux содержит подробные руководства по systemd. Многие рекомендации применимы в других дистрибутивах.
• Документация вашего дистрибутива часто содержит локальные нюансы (например, путь к юнитам).

Image Credit: Bert Heymans on Flickr

Завершение: systemd объединяет управление сервисами и журналом в одну систему. Он даёт много возможностей для автоматизации, безопасности и наблюдаемости. Для повседневных задач достаточно нескольких команд systemctl и journalctl; для более сложных сценариев — написание собственных unit‑файлов и настройка ограничений безопасности.