Введение в Systemd. Часть 4






С целью обеспечения совместимости с System-V и LSB Systemd поддерживает работу с «традиционными» init-сценариями. Эти сценарии используются не только в SysV-init системах, но также и в системах, использующих Upstart. Такие сценарии интерпретируются оболочкой и при запуске требуют определения параметров, таких как 'start', 'stop' и 'restart'; этот подход в управлении службами используется с первых дней жизни SysV-init.

Systemd


Разработчики коммерческого ПО обычно поставляют необходимые init-сценарии, управляющие необходимыми службами. На основе обнаруженных в системе init-сценариев Systemd автоматически генерирует соответствующие unit-файлы, таким образом создавая интерфейс к SysV-init службам; однако Systemd будет игнорировать обнаруженные SysV и LSB сценарии, если обнаружит одноимённые unit-файлы.

Группы

Systemd поддерживает работу с cgroups, помещая процессы запускаемых сервисов в одноимённые группы. Современные ядра поддерживают cgroups и предлагают широкие возможности для изоляции и выделения аппаратных ресурсов процессам.

Дочерние процессы наследуют ограничения в пределах группы. Это позволяет Systemd управлять группами процессов как связанными юнитами, что даёт, например, возможность гарантированно завершать все дочерние процессы сервиса. Кроме того, администраторы могут управлять выделением ресурсов сервисам при помощи традиционного интерфейса cgroup, избегая необходимости настраивать ограничения для каждого процесса.

Общий подход

Systemd поставляется с набором юнитов, выполняющих различные базовые задачи в процессе инициализации системы. Некоторые из них работают подобно сервисам. Например, юнит fsck-root.service запускает проверку корневой ФС в случае необходимости перед тем, как юнит remount-rootfs.service смонтирует её в режиме «чтение-запись»; юниты hwclock-load и hwclock-save обслуживают синхронизацию системного времени с аппаратными часами. В SysV-init и Upstart-дистрибутивах эти и ещё множество подобных задач решаются при помощи shell-сценариев, расположенных в /etc/rc.sysinit или в /etc/rcS.d/*. Эти сценарии очень различаются в разных семействах дистрибутивов и, таким образом, вы увидите совершенно разные реализации одного и того же в RedHat, Debian и OpenSUSE. По этой причине, например, пользователи RedHat успешно смогут выполнить настройку раскладки в /etc/sysconfig/keyboard, но у них не получится сделать то же самое в Debian.

Многие юниты Systemd запускают программы, написанные на Си, которые обычно более быстрые и надёжные, нежели shell-сценарии, ранее выполнявшие те же задачи. Интегрируя в себе решение задач, ранее выполнявшихся отдельными shell-сценариями, Systemd таким образом пытается свести на нет большинство различий между существующими семействами дистрибутивов. Это значительно облегчает работу разработчикам, поскольку теперь им необходимо лишь создать необходимые для управления их продуктами unit-файлы, опираясь на интерфейс Systemd, а не множество различных решений в разных дистрибутивах. Очевидно, что поддержка SysV-init сценариев для всех популярных систем — гораздо более трудоёмкая задача.

В заключение

Больше информации о концепциях Systemd вы можете получить в man-страницах, а также из коллекции ссылок на сайте Lennart Poettering.

Источник