Systemd — сердце современного Linux

Привет! Если ты начинаешь свой путь в администрировании Linux, то рано или поздно столкнёшься с загадочным словом Systemd. Что это такое? Почему все о нём говорят? И как с ним работать? Давай разберёмся вместе!

Что такое systemd?

Представь себе дирижёра оркестра. Его задача — следить, чтобы все музыканты начинали играть вовремя, взаимодействовали друг с другом и создавали гармоничную мелодию. Systemd — это такой же дирижёр, но для твоей операционной системы Linux.

Главный процесс (PID 1): Systemd запускается самым первым (сразу после ядра Linux) и имеет идентификатор процесса (PID) равный 1. Он становится «родителем» всех остальных процессов в системе.
Менеджер всего: Он управляет запуском и остановкой служб (services), монтированием дисков (mounts), сетевыми настройками, логированием и многим другим.
Замена старых систем: Systemd пришёл на смену более старым системам инициализации (таким как SysVinit или Upstart), предложив более быстрый, параллельный и управляемый способ загрузки системы.

Основной инструмент: команда systemctl

Для общения с «дирижёром» Systemd используется одна главная команда — systemctl. С её помощью ты можешь управлять службами:

Команда	Назначение	Пример
`systemctl status [служба]`	Посмотреть статус службы (работает? ошибка?)	`systemctl status sshd`
`sudo systemctl start [служба]`	Запустить службу	`sudo systemctl start httpd`
`sudo systemctl stop [служба]`	Остановить службу	`sudo systemctl stop httpd`
`sudo systemctl restart [служба]`	Перезапустить службу	`sudo systemctl restart sshd`
`sudo systemctl enable [служба]`	Включить автозапуск службы при загрузке	`sudo systemctl enable sshd`
`sudo systemctl disable [служба]`	Отключить автозапуск службы	`sudo systemctl disable httpd`

Единицы (Units): строительные блоки systemd

Systemd управляет не только службами. Всё, чем он управляет, называется «единицей» (Unit). У каждой единицы есть свой тип, обозначаемый расширением файла конфигурации:

.service: Самый главный тип — это службы (демоны, фоновые процессы, например, веб-сервер httpd.service).
.socket: Специальные сокеты, которые слушают порт. Когда на сокет приходит запрос, Systemd запускает связанную с ним службу. Экономит ресурсы!
.timer: Таймеры, которые запускают службы по расписанию (современная замена Cron).
.mount: Управляет монтированием файловых систем (вместе с /etc/fstab).
.target: Цели — группы других единиц, определяющие состояние системы (об этом ниже).

Цели (Targets): уровни работы системы

Раньше в Linux были «уровни выполнения» (runlevels). Systemd заменил их на «цели» (Targets). Target — это просто группа служб, которые должны быть запущены для достижения определенного состояния системы.

Самые важные цели:

multi-user.target: Стандартный режим для сервера. Запускает всё необходимое для работы (сеть, службы), но без графического интерфейса.
graphical.target: Стандартный режим для рабочей станции. Включает всё из multi-user.target плюс графический интерфейс.
rescue.target / emergency.target: Режимы для восстановления системы при сбоях.

Ты можешь посмотреть текущую цель по умолчанию командой systemctl get-default и изменить её через sudo systemctl set-default [цель].

Зависимости: как службы дружат между собой

Systemd отлично управляет зависимостями. Если служба А не может работать без службы Б, Systemd проследит, чтобы Б запустилась первой.

Директива	Назначение	Сила
`Requires=[Unit]`	Сильная зависимость. При запуске этой службы запускается и указанная служба. Если указанная служба падает, то падает и эта служба (или она не может запуститься).	Самая сильная (Критическая)
`Wants=[Unit]`	Слабая зависимость. При запуске этой службы делается попытка запустить указанную службу. Однако, если указанная служба падает или не запускается, это не влияет на текущую службу.	Слабая (Рекомендательная)
`WantedBy=[Target]`	Используется в секции `[Install]` Unit-файла. Она сообщает Systemd, что данная служба должна быть запущена (wanted) при активации указанного Target-а (например, `multi-user.target`).	Связь с Target

Журнал (Journald): все логи в одном месте

Systemd имеет свою собственную систему журналирования — Journald. Она собирает логи всех системных компонентов и служб в единый, структурированный бинарный журнал.

Команда: journalctl — твой основной инструмент для просмотра логов.
Фильтрация: journalctl -u sshd (по службе), journalctl -k (только ядро), journalctl -f (в реальном времени).
Постоянство: По умолчанию журнал хранится в памяти и очищается при перезагрузке. Чтобы сделать его постоянным, создай каталог: sudo mkdir /var/log/journal.

Продвинутые штуки (кратко)

Systemd умеет гораздо больше:

Активация по сокету (.socket): Запускает службу только тогда, когда к ней обращаются по сети (например, веб-сервер запускается только при первом запросе).
Таймеры (.timer): Планируют запуск служб по расписанию, заменяя старый добрый cron.
Самовосстановление (Restart=): Если служба внезапно «упадет», Systemd может автоматически перезапустить ее.
Безопасная Настройка (systemctl edit): Позволяет изменять конфигурацию системных служб, не трогая оригинальные файлы, через механизм «файлов переопределения» (override.conf).
Cgroups (Control Groups): Systemd использует Cgroups для ограничения ресурсов (CPU, память, диск) для служб и пользователей, обеспечивая стабильность системы.

Cgroups (Control Groups) и Systemd

Cgroups (Control Groups) — это функция ядра Linux, которая позволяет распределять, ограничивать и резервировать системные ресурсы (CPU, память, I/O) для групп процессов. Systemd активно использует Cgroups для управления всеми процессами в системе.

Архитектура Cgroups

Cgroups организуются в виде контроллеров и иерархии срезов (slices):

Контроллеры: Определяют тип ресурса. Основные контроллеры: CPU (процессорное время), Memory (память), BlockIO (дисковый ввод/вывод).
Иерархия: Контроллеры организованы в древовидную структуру, где ограничения и веса применяются на каждом уровне. Фактические настройки можно увидеть в /sys/fs/cgroups.

Срезы (Slices) — основное деление

Systemd использует срезы (Slices) для первичного разделения ресурсов на самом высоком уровне. Все процессы в системе попадают в один из трех основных срезов:

Срез	Назначение
`system.slice`	Системные процессы и демоны (службы, запущенные через Systemd).
`machine.slice`	Виртуальные машины (VM) и контейнеры.
`user.slice`	Сеансы и процессы, запущенные обычными пользователями.

Важный вывод: Срезы являются равноправными (peers). По умолчанию каждый срез имеет одинаковый вес, что может привести к неожиданным результатам.

Распределение ресурсов (CPU Shares)

CPU Shares — это относительный вес или доля ЦПУ, которую получает Cgroup (срез, область, служба) при условии, что система находится под полной нагрузкой.

Вес по умолчанию: 1024 — это стандартное значение CPU Shares.
Сравнение: Если два среза имеют вес 1024, каждый из них получит 50% доступного ЦПУ (1024 / (1024+1024)).
Иерархия: Shares применяются рекурсивно:
- Shares срезов определяют, какую долю ЦПУ получит срез.
- Shares Областей (Scopes) внутри среза определяют, как ресурс делится внутри среза.
- Shares Служб/Юнитов внутри области/среза определяют, как ресурс делится между службами.

Проблема равноправия срезов

Если я, как пользователь, запускаю активный процесс, который попадает в user.slice, а системные службы (в system.slice) тоже активны, то:

user.slice (я) получает 50% ЦПУ (вес 1024).
system.slice получает 50% ЦПУ (вес 1024).
В итоге, один пользовательский процесс может конкурировать за ресурсы со всеми системными демонами вместе взятыми, что может серьезно повлиять на стабильность сервера.