В чем преимущество системы инициализации systemd linux

Обновлено: 04.07.2024

Systemd — прародитель всех процессов, ответственный за поднятие Linux хоста.

Сегодня мы поговорим про systemd — подсистему управления службами в Linux, заменившую классический init и SystemV. И замена эта, надо сказать, достойная. Как и для большинства разработчиков, связанных с Linux, для меня init и SystemV — это, в первую очередь, запуск служб и загрузка системы, а уже потом — управление запущенными процессами.

Как и init, systemd — прародитель всех процессов, так сказать, демон инициализации демонов, ответственный за поднятие хоста в рабочее состояние.

25–26 ноября, Москва и онлайн, От 24 000 до 52 000 ₽

Некоторые функции, реализуемые systemd, используются для управления системой, например, для монтирования файловых систем, управления устройствами, таймерами, а также запуска и управления системными службами для запуска системы.

В этой статье мы рассмотрим базовые функции systemd, которые используются как для запуска системы, так и после него.

Загрузка Linux

Хотя загрузка Linux – сложный и многоэтапный процесс, здесь нет никакой «магии». Перед тем как вдаваться в детали, предлагаю пройтись по процессам, которые происходят с момента включения машины до момента входа в систему.

Как правило, процесс загрузки воспринимают как нечто цельное, но это неправильно.

Загрузка состоит из, как минимум, трех разных этапов:

загрузка аппаратной части: запуск «железа»;
загрузка Linux: загрузка ядра, а затем, systemd;
запуск рабочей среды: systemd подготавливает систему к работе.

Запуск Линукса начинается после того, как ядро запустило либо init, либо systemd — в зависимости от того, что используется в дистрибутиве. Демоны init и systemd запускают и управляют всеми другими процессами, поэтому их часто называют прародителем всех процессов.

Важно четко понимать различия между аппаратной загрузкой, загрузкой Linux и запуском рабочей среды. Если вы понимаете, где заканчивается один процесс и начинается другой, а также какую роль играет каждый из них в запуске системы до рабочего состояния, вы с легкостью найдете, в каком конкретно месте «загрузки» возникает проблема.

Запуск Linux — последний этап процесса загрузки. Именно он позволяет вывести систему в рабочее состояние, когда вы можете работать с ней. Запуск начинается тогда, когда ядро передает управление systemd.

Что не так с systemd

Systemd вызывает довольно противоречивые реакции у системных администраторов и технических специалистов. Тот факт, что systemd ответственен за такое большое число разных задач и процессов, привел к тому, что многие разработчики и системные администраторы высказываются резко против этого демона, отказываясь от его использования в пользу классических решений.

SystemV и systemd — это два разных метода запуска Линукса. Сценарии запуска SystemV и демона init — это старый метод. А юниты target в systemd — более современный. Хотя большинство современных дистрибутивов используют для запуска, завершения работы и управления процессами systemd, есть те, что это не делают. Одна из причин — некоторые создатели дистрибутивов и системные администраторы предпочитают старый SystemV.

Однако я считаю, что у обоих методов свои преимущества.

Чем хорош SystemV

SystemV более доступен. Запуск выполняется при помощи bash-скриптов. После того как ядро запускает init — скомпилированный бинарный файл — init запускает скрипт rc.sysinit, который выполняет множество задач для инициализации системы. После завершения rc.sysinit, init запускает /etc/rc.d/rc , который, в свою очередь, запускает различные демоны, определенные сценариями запуска SystemV в /etc/rc.d/rcX.d , где «X» — уровень выполнения (runlevel).

Кроме самого init, все эти скрипты и демоны — открыты и легко читаемы. Не составит никакого труда изучить эти скрипты и понять, как работает каждый из них и что конкретно происходит во время запуска системы. Однако я не думаю, что кто-то из системных администраторов часто этим занимается. Каждый запускаемый скрипт нумерован таким образом, чтобы запускать соответствующую службу в определенной последовательности. Службы запускаются последовательно и по одной за раз.

Systemd обязан своим появлением сотрудникам Red Hat — Леннарту Пёттерингу и Кэю Сиверсу. Фактически, это комплексная система больших, скомпилированных исполняемых файлов, логику которых не понять без доступа к исходному коду. Но поскольку systemd — open-source проект, проблем с «доступом к исходному коду» не возникает, просто это не очень удобно.

Однако своим появлением systemd значительно опровергает базовые принципы философии Linux. Как бинарный файл, systemd закрыт от прямого редактирования или просмотра системными администраторами. При этом он пытается «делать всё». Например, управлять запущенными службами. С другой стороны, он дает гораздо больше информации о состоянии, чем SystemV.

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

Чем хорош systemd

Systemd параллельно запускает столько служб, сколько возможно, в зависимости от текущей стадии запуска системы. Естественно, это существенно ускоряет запуск. Времени от включения до экрана входа в систему тратиться гораздо меньше, чем в случае с SystemV.

Systemd управляет практически каждым аспектом работающей системы. Он может управлять запущенными службами, предоставляя значительно больше информации о состоянии, чем SystemV. Он также управляет аппаратной частью, процессами и группами процессов, монтированием файловых систем и многим другим (звучит знакомо, не правда ли?).

Инструментарий systemd — компилированные бинарные файлы, но набор инструментов открыт, потому что все конфигурационные файлы — это ASCII текст. Конфигурацию запуска можно менять через различные инструменты командной строки или GUI. Также можно менять или добавлять различные конфигурационные файлы, при необходимости.

Держать всё под контролем: сравнение систем мониторинга

Муки выбора

Зачем выбирать что-то одно, если можно работать с обеими подсистемами?

Хотя в этом вопросе выбор уже сделан за меня, мои хосты в любом случае загружаются и работают, что все-таки, главное. Как конечный пользователь и системный администратор, мне нужно, чтобы я мог выполнять свои задачи, например, писать статьи вроде этой, устанавливать обновления, или писать скрипты, чтобы автоматизировать все, что можно и что нельзя. До тех пор, пока я могу выполнять всю работу, я не особо задумываюсь о порядке запуска, который вшит в моем дистрибутиве.

А вот о чем я думаю, так это об исправлении ошибок во время запуска или при управлении службами. Вне зависимости от используемой подсистемы, я знаю достаточно, чтобы восстановить последовательность действий при загрузке и отследить ошибки, исправив их.

Чем заменить SystemV

В прошлом уже предпринималось несколько попыток заменить SystemV чем-то более современным. Примерно два релиза подряд Fedora использовала Upstart, призванный заменить устаревающий SystemV, но Upstart не заменял init и не вносил значимых изменений в запуск. Поскольку Upstart практически не решал проблем SystemV, все усилия, связанные с его разработкой, были быстро заброшены в пользу systemd.

Несмотря на то что большинство разработчиков Linux согласны, что заменить устаревший SystemV – хорошая идея, именно за это systemd так не любят многие системные администраторы и разработчики. Вместо того чтобы пересказывать все так называемые проблемы, с которыми сталкиваются или сталкивались пользователи systemd, я лучше дам ссылку на две хороших, по моему мнению, статьи, которые ответят на все возможные вопросы по этой теме:

Линус Торвальдс, создатель ядра Линукса, кажется, не заинтересован в systemd. В 2014 году в статье ZDNet он четко высказался по этому поводу:

На самом деле, у меня нет какого-то особого мнения насчет systemd. Да, у меня были проблемы с некоторыми разработчиками, которые, как мне кажется, слишком легкомысленно относятся к ошибкам и совместимости и я думаю, некоторые решения просто безумны (например, мне не нравятся бинарные логи), но это все детали, а не фундаментальные проблемы.

Если вы вдруг не знаете манеры разговора Линуса, я напомню: если ему что-то не нравится, он очень откровенен, резок и прямолинеен в своих высказываниях. Можно сказать, его полюбили именно за его манеру высказываться о том, что ему не нравится.

В 2013 Пёттеринг написал пост в своем блоге, где развенчал мифы о systemd, попутно рассказав о цели его создания.

Задачи systemd

В зависимости от параметров, используемых при компиляции (о которых мы здесь не говорим) у systemd включает до 69 исполняемых файлов, которые выполняют, кроме прочего, следующие задачи:

systemd запускается как PID 1 и выделяет запуску системы столько служб в параллельном режиме, сколько нужно. Это приводит к ускорению загрузки. Он также управляет последовательностью завершения работы.
systemctl предоставляет пользовательский интерфейс для управления службами.
Для обеспечения обратной совместимости предлагается поддержка SystemV и LSB.
Управление службами и логами дает больше информации о состоянии служб, чем SystemV.
Включает инструменты для базовой настройки системы, например: имя хоста, дата, язык, список авторизированных пользователей, запущенные контейнеры и виртуальные машины, системные учетные записи, рабочие директории и настройки, демоны для управления базовой настройкой сети, синхронизация сетевого времени, пересылка журналов и разрешение доменных имен.
Управление сокетами.
Таймеры systemd предоставляют расширенные cron-подобные возможности, включая запуски скриптов, привязанные ко времени от старта системы, запуск systemd, время последнего запуска таймера и многое другое.
Инструментарий для анализа дат и времени, используемых в спецификациях таймеров.
Монтирование и размонтирование файловых систем с иерархическим уведомлением обеспечивает более безопасное каскадирование.
Позволяет создавать и управлять временными файлами, включая их удаление.
Интерфейс с D-Bus позволяет запускать скрипты, когда устройства подключены или извлечены. Это позволяет рассматривать все устройства, подключаемые или нет, как plug-and-play, что сильно упрощает работу с ними.
Инструмент для анализа последовательности загрузки позволяет найти службы, на запуск которых тратится больше всего времени.
Создаёт журналы для хранения системных логов и включает инструменты для управления этими журналами.

Архитектура

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

Архитектура systemd, автор Shmuel Csaba Otto Traian (CC BY-SA 3.0)

Если описывать все функции systemd, это заняло бы целую книгу. Но вам необязательно понимать, как компоненты systemd взаимодействуют друг с другом. Достаточно знать о компонентах и программах, управляющих различными службами Linux и позволяющих работать с логами и журналами. Но уже сейчас очевидно, что systemd это не какое-то монолитное чудовище, каким его считают некоторые критики.

systemd как PID 1

Systemd это PID 1. Некоторые функции, потенциал которых гораздо более обширный, чем в SystemV3 init, позволяют управлять многими аспектами Linux, включая монтирование файловых систем и запуск служб. Любых задач, не связанных с последовательностью запуска системы в этой статье мы не касаемся.

Итак, для начала, systemd монтирует файловую систему в /etc/fstab , включая файлы подкачки (swap) или разделы. На данном этапе systemd получает доступ к конфигурационным файлам в /etc , включая свой собственный. Для выбора загрузки он использует свою конфигурационную ссылку в /etc/systemd/system/default.target .

default.target — это символичная ссылка на настоящий target. Для настольного ПК, это, как правило, graphical.target, что эквивалентно runlevel 5 в SystemV. Для серверных решений по умолчанию стоит multi-user.target, эквивалентный runlevel 3 в SystemV. emergency.target аналогичен однопользовательскому режиму. Target’ы и службы в systemd называются юнитами.

В таблице я сравниваю target systemd со старой системой запуска runlevel в SystemV. systemd предоставляет target псевдонимы (алиасы) для обеспечения обратной совместимости. Алиасы позволяют скриптам — и системным администаторам — использовать команды SystemV, как init 3 для смены runlevel. Естественно, команды SystemV передаются в systemd для интерпретации и выполнения.

Сравнение runlevel SystemV с target systemd и некоторые алиасы target’ов

В конфигурационных файлах каждого target расписан набор зависимостей. Systemd запускает требуемые службы для запуска хоста на определенном уровне функциональности. Когда все зависимые объекты запущены, система работает на соответствующем уровне target. В таблице юниты с максимальной функциональностью указаны в верхних строках, к последним строкам их функциональность снижается.

Systemd также просматривает старые каталоги SystemV init для поиска каких-либо файлов запуска. И если подсистема их находит, она использует их в качестве конфигурационных файлов для запуска служб, описанных этими файлами. Устаревшая сетевая служба –— хороший пример той, что все еще использует файлы запуска SystemV в Fedora.

Схема 3 скопирована со страницы описания процесса загрузки проекта man-pages. В ней указана общая последовательность событий во время запуска system и основные требования по порядку загрузки.

Карта запуска systemd

Юниты sysinit.target и basic.target считаются контрольными точками в процессе запуска. Хотя одна из главных целей systemd — параллельный запуск служб, некоторые демоны и юниты должны запускаться первыми. Такие контрольные точки нельзя пропустить до тех пор, пока все необходимые службы и юниты, установленные в рамках этой контрольной точки, не будут запущены.

Sysinit.target завершается, когда все юниты, от которых он зависит, выполнены. Все эти юниты, монтирование файловой системы, настройка файла подкачки, запуск udev, установка генератора случайных чисел, инициализация низкоуровневых служб и настройка криптографических служб (если одна или несколько файловых систем зашифрованы) должны быть завершены для выполнения sysinit.target. А внутри самого sysinit.target, все процессы могут выполняться параллельно.

Юнит sysinit.target запускает все низкоуровневые службы и юниты, необходимые для достижения системой минимальной функциональности. Без их загрузки система не может перейти к basic.target.

После выполнения sysinit.target, systemd запускает все требуемые для нового target юниты. Basic.target обеспечивает дополнительную функциональность, запуская юниты, которые нужны для всех остальных target’ов. Сюда входят такие вещи, как установка путей к рабочим директориям, сокеты и таймеры.

Наконец, инициализируются target пользовательского уровня: multi-user.target или graphical.target. multi-user.target должен быть выполнен до того, как будут достигнуты зависимости graphical.target. Указанные на схеме 3 target’ы — это обычные юниты запуска. Как только один из них выполнен, запуск завершен. Если по умолчанию установлен multi-user.target, вы попадете на текстовый вариант логина в консоли. Если установлен graphical.target вы увидите графический интерфейс входа в систему; конкретный интерфейс логина GUI, который вы видите, зависит от настроек.

В мануале man-pages подробно описана последовательность и карта загрузки на начальный RAM диск (initrd), а также процесс завершения работы systemd.

systemctl list-dependencies graphical.target

Обратите внимание, что это команда полностью раскрывает юниты верхнего уровня, необходимые для запуска системы в GUI. Используйте — all, чтобы развернуть все остальные юниты.

systemctl list-dependencies --all graphical.target

Вы можете искать строки, например, «target,» «slice,» и «socket», используя инструменты поиска команды less. Теперь попробуйте.

systemctl list-dependencies multi-user.target

systemctl list-dependencies rescue.target

systemctl list-dependencies local-fs.target

systemctl list-dependencies dbus.service

Этот инструмент помогает мне визуализировать специфику зависимостей запуска хоста, на котором я работаю. Попробуйте немного изучить древо запуска для одного или нескольких ваших Linux хостов. Но будьте осторожны: как написано в руководстве man-page:

Обратите внимание, эта команда лишь выводит юниты, загруженные в текущий момент в память менеджером служб. В частности, эта команда не подходит для получения полного списка всех обратных зависимостей конкретного юнита, поскольку она не покажет зависимостей незагруженных юнитов.

Пост скриптум

Даже касаясь systemd лишь поверхностно, очевидно, что это мощный, но сложный инструмент. Также очевидно, что systemd не является монолитным, огромным или непонятным исполняемым файлом. Скорее, это большое число небольших компонентов и подкоманд, созданных для выполнения конкретных задач.

В следующей статье мы детально коснемся загрузки systemd, конфигурационных файлов, смены target по умолчанию, а также поговорим о том, как создать простой юнит.

В операционной системе Linux и других системах семейства Unix после завершения загрузки ядра начинается инициализация Linux системы, сервисов и других компонентов. За это отвечает процесс инициализации, он запускается ядром сразу после завершения загрузки, имеет PID 1, и будет выполняться пока будет работать система.

Процесс инициализации запускает все другие процессы, которые должны быть запущены, это родительский процесс для всего, что выполняется в системе. Другие процессы могут тоже создавать дочерние процессы, но если родительский процесс завершается, для его дочерних процессов родительским становится процесс инициализации.

Системы инициализации Linux

За время развития операционных систем были созданы различные системы инициализации Linux. В разных дистрибутивах использовались разные системы. В этой статье мы рассмотрим лучшие системы инициализации, которые вы можете сейчас использовать. Мы начнем с более старых систем с меньшим функционалом, чтобы понять с чего все начиналось, затем подойдем к более новым, созданным в последнее время.

1. System V Init

System V или SysV - это довольно старая, но до сих пор ещё популярная система инициализации Linux и Unix подобных операционных систем. Она была основой для создания многих других систем инициализации, а также первой коммерческой системой инициализации разработанной для Unix в AT&T. Она была разработана еще в 1983 году.

Почти все дистрибутивы Linux изначально использовали SysV. Исключением была только Gentoo, в которой использовалась собственная система инициализации и Slackware, с инициализацией в стиле BSD.

Основные возможности SysV:

Написание файлов запуска служб на bash;
Последовательный запуск служб;
Сортировка порядка запуска с помощью номеров в именах файлов;
Команды для запуска, остановки и проверки состояния служб.

Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине.

С момента ее разработки прошло много лет и из-за некоторых недостатков были разработаны другие системы для ее замены, они хоть и имели новые функции и были более эффективны, но они были по-прежнему совместимы с SysV.

2. OpenRC

OpenRC - это система инициализации Linux и Unix подобных операционных систем совместимая с Sys V Init и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:

Поддержка зависимостей служб;
Поддержка параллельного запуска служб;
Поддерживает настройку в одном отдельном файле;
Работает как демон;

По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.

3. Systemd

Systemd - это новая система инициализации Linux. Она была введена по умолчанию в Fedora 15, а сейчас используется почти во всех популярных Linux дистрибутивах. Это не только инициализирующий процесс, поддерживающий огромное количество возможностей, но и набор инструментов для управления службами и этими возможностями из системы. Основная цель - иметь полный контроль над всеми процессами во время их запуска и на протяжении всего выполнения.

Systemd очень сильно отличается от всех существующих систем инициализации, тем как она работает с сервисами, и даже конфигурационными файлами сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот ее основные особенности:

Понятный, простой и эффективный дизайн;
Параллельная загрузка служб на основе зависимостей;
Поддерживается завершение дополнительных процессов;
Поддерживается собственный журнал с помощью journald;
Поддерживается планирование заданий с помощью таймеров Systemd;
Поддерживается управление сетью с помощью networkd;
Для управления DNS используется systemd-resolved;
Хранение журналов в бинарных файлах;
Сохранение состояния сервисов linux systemd для возможного восстановления;
Улучшенная интеграция с Gnome;
Запуск сервисов по требованию;

4. Runinit

Runinit - это кроссплатформенная система инициализации, которая может работать в GNU Linux, Solaris, BSD и MacOS. Это отличная альтернатива для SysV с поддержкой мониторинга состояния служб.

Здесь есть некоторые интересные особенности, которых нет в других системах инициализации:

Полный контроль сервисов, каждый сервис привязывается к своему каталогу;
Надежное средство журналирования и ротации логов;
Быстрая система загрузки и выключения;
Портативность;
Легкое создание файлов конфигурации служб;
Небольшое количество кода системы инициализации.

5. Upstart

Upstart - это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:

Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
Запуск и остановка служб на основе событий;
Генерация событий во время запуска и остановки служб;
События могут быть отправлены обычными процессами;
Связь с процессом инициализации через DBus;
Пользователи могут запускать и останавливать свои процессы;
Перезапуск служб, которые неожиданно завершились;
Параллельная загрузка сервисов;
Автоматический перезапуск служб;

Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd. В последнее время всё меньше используются скрипты SysV init и всё больше применяются юнит файлы Systemd. Рано или поздно Systemd вытеснит и полностью заменит Upstart в Ubuntu.

Выводы

Как я уже говорил, система инициализации запускает и управляет всеми другими процессами в системе Linux. SysV до недавнего времени была основной системой инициализации в большинстве дистрибутивов Linux, но из-за некоторых своих недостатков для нее было разработано несколько замен, в том числе Systemd.

Какие системы инициализации Linux используются в вашем дистрибутиве? В списке обозначены не все существующие системы, какую из них нужно добавить в список? Напишите в комментариях!

Примечание: В системе инициализации SysV главным процессом является процесс init, а в системе инициализации systemd — (одноименный) процесс systemd.

С течением времени в Linux появилось большое разнообразие систем инициализации. В данной статье мы рассмотрим наиболее популярные из них, а также сравним SysV и systemd.

Спор вокруг систем инициализации в Linux

В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.

Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.

В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.

Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?

systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.

В результате systemd становится самостоятельной платформой, и её повсеместное распространение непреднамеренно препятствует разработке программного обеспечения, которое является переносимым и совместимым с операционными системами, не поддерживающими systemd. Но действительно ли всё так печально? Конечно, нет. Прежде всего, это проект с открытым исходным кодом, и у людей есть выбор: использовать его или нет. Пользователи и разработчики могут извлечь выгоду из наличия нескольких конкурирующих систем инициализации, и нет вины systemd в том, что основные дистрибутивы переключились на нее из-за её плюсов.

Системы инициализации Linux

Примечание: System V — это первая коммерческая UNIX-подобная операционная система, которая была выпущена в 1983 году.

Если процесс init по каким-либо причинам не смог стартовать, то не произойдет запуска последующих процессов и система перейдет в особое (вызванное появлением критической ошибки) состояние ядра, называемое Kernel Panic.

В SysV имеется шесть состояний системы, известных как уровни выполнения (runlevels), и всем процессам и службам сопоставляется определенный уровень выполнения. Данная система инициализации также предлагает простые в использовании команды и методы для управления уровнями выполнения и связанными с ними службами.

Runlevel 0 — завершает работу системы.

Runlevel 3 — многопользовательский режим с поддержкой сети, но без графического интерфейса. Чаще всего серверные версии Linux работают именно на этом уровне выполнения.

Runlevel 4 — не используется. Пользователь может настраивать этот уровень исходя из его целей.

Runlevel 5 — схож с режимом 3, но здесь запускается графический интерфейс. В этом режиме работают десктопные версии Linux.

Runlevel 6 — перезагружает систему.

Значения для каждого уровня выполнения варьируются в зависимости от вашего дистрибутива Linux. Есть дистрибутивы (например, Ubuntu), которые используют Runlevel 2 для многопользовательского графического режима с поддержкой сети, другие дистрибутивы (например, Fedora) для того же самого используют Runlevel 5.

В операционной системе, использующей SysV, ядро запускает файл /sbin/init, который, в свою очередь, загружает параметры и выполняет директивы, определенные в файле конфигурации — /etc/inittab. Этот файл задает уровни выполнения для всей системы, определяет, для каких терминалов следует создавать getty (процессы инициализации терминала), запускает процессы входа в терминал, запускает скрипт /etc/init.d/rcS, а также влияет на порядок выполнения других runlevel-скриптов.

Запуск служб происходит в заранее определенной последовательности. Следующий скрипт в цепочке запуска выполняется только в том случае, если был выполнен предыдущий скрипт. Если во время своего выполнения скрипт зависнет, то следующему скрипту придется ждать, пока у текущего не истечет время ожидания. Данная непредвиденная задержка исполнения скрипта делает весь процесс инициализации системы менее эффективным и, в конечном счете, более медленным.

В ОС, использующей систему инициализации SysV, обычно присутствует специальная программа, используемая для управления службами во время работы системы. Вы можете проверить состояние службы или всех служб, а также запустить или остановить службу при помощи следующих команд:

systemd

systemd — это относительно новая система инициализации Linux, представляющая собой набор утилит для запуска и управления всеми типами процессов и служб (а также устройствами, сокетами, точками монтирования, областью подкачки, модулями и пр.).

Unit — это модуль, отвечающий за отдельно взятую службу, точку монтирования, подключаемое устройство, файл подкачки, виртуальную машину и тому подобные ресурсы.

Target — это аналог уровней выполнения из SysV, состоящий из нескольких unit-ов.

systemd выполняет unit для достижения target. Инструкции для каждого устройства находятся в каталоге /lib/systemd/system/.

Для управления службами в systemd применяется специальная утилита — systemctl. Например:

Еще одной важной программой в наборе инструментов systemd является утилита journalctl. Она позволяет просматривать и управлять демоном логов journald. Лог-файл systemd является двоичным файлом, и использование journalctl сильно упрощает работу с ним. Вот несколько примеров:

Плюсы системы инициализации systemd:

Новый, современный и эффективный дизайн.

Более простой процесс загрузки.

Параллельная обработка задач при загрузке системы.

Простой синтаксис unit-файлов.

Возможность удаления дополнительных компонентов.

Низкий уровень потребления ресурсов.

Улучшен механизм зависимостей.

Инструкция инициализации процессов хранится в файле конфигурации, а не в скрипте оболочки.

Планирование задач с использованием systemd Calendar Timers.

Ведение лог-файла с помощью службы journald.

Лог-файлы хранятся в двоичных файлах.

Состояние systemd может быть сохранено для последующего вызова в будущем.

Отслеживание исполняемого процесса через механизм контейнеризации cgroup.

Улучшенная интеграция с GNOME для обеспечения совместимости.

Минусы системы инициализации systemd:

Всё собрано в одном месте.

Не соответствует стандартам POSIX.

Upstart

Upstart — это гибридная система инициализации (могут использоваться как скрипты запуска SysV, так и сценарии systemd), созданная разработчиками дистрибутива Ubuntu в качестве замены системы инициализации SysV. В отличие от SysV, которая создавалась для работы в статическом окружении, Upstart предназначалась для работы в более гибком окружении.

По сравнению с SysV, в Upstart можно выделить три основных преимущества, а именно: управление службами на основе событий (вместо уровней выполнения), асинхронный запуск служб и автоматический перезапуск аварийно завершенных служб.

Когда происходит какое-либо событие, Upstart обнаруживает это событие и вносит необходимые изменения. Событием может быть всё, что связано с различными состояниями системы, например: USB-накопитель подключается/извлекается из системы или запускается/останавливается служба.

Для управления уровнем запуска различных служб в Upstart применяется специальная утилита — initctl, например:

$ initctl status <job> (отображение состояния службы)

$ initctl list (отображение списка служб)

OpenRC

OpenRC — это кроссплатформенная система инициализации на основе зависимостей, которая совместима с SysV. Несмотря на то, что OpenRC вносит некоторые улучшения в SysV, она не является её абсолютной заменой.

Может работать во многих дистрибутивах Linux, включая Gentoo.

Скрипты инициализации с отслеживанием состояния.

Ограничение ресурсов для каждой службы.

Загрузка на основе зависимостей.

Запускается в виде демона.

Параллельный запуск служб и многое другое.

runit

runit — также кроссплатформенная система инициализации, которая может работать на Solaris, операционных системах семейства BSD и macOS. В целом очень похожа на SysV. Может использоваться сама по себе или же в качестве альтернативы для SysV, systemd, а также в сочетании с OpenRC.

К основным преимуществам runit относятся:

Быстрая загрузка и выключение системы.

Логирование вывода процесса и ротация логов.

Автоматическое выключение и запуск сервисов при появлении новых сервисов в списке, либо удалении старых из списка.

Возможность ведения нескольких независимых списков сервисов одновременно (например, для каждого пользователя отдельно и для системы в целом).

Сравнение SysV и systemd

Функции	SysV	systemd
Зависимость D-Bus	Нет	Да
Управление устройствами с помощью udev	Нет	Да
Активация по таймеру	cron/at	Проприетарная
Управление квотами	Нет	Да
Автоматическая обработка зависимостей служб	Нет	Да
Завершение процессов пользователей при выходе из системы	Нет	Да
Управление пространством подкачки	Нет	Да
Интеграция SELinux	Нет	Да
Поддержка шифрованных HDD	Нет	Да
Загрузка статических модулей ядра	Нет	Да
Графический интерфейс пользователя (GUI)	Нет	Да
Перечисление всех дочерних процессов	Нет	Да
Совместимость с SysV	Да	Да
Интерактивная загрузка	Нет	Да
Переносимость на отличную от x86 архитектуру процессора	Да	Нет
Параллельный запуск служб	Нет	Да
Ограничение ресурсов для каждой службы	Нет	Да
Легко расширяемый скрипт автозагрузки	Да	Нет
Раздельные код и файл конфигурации	Да	Нет
Автоматический расчет зависимостей	Нет	Да
Подробный вывод отладочной информации	Да	Нет
Количество файлов	75 файлов	900 файлов + Glib + D-Bus

Как определить какая система инициализации у меня?

Способ №1: Команда ps

С помощью команды ps мы можем отобразить информацию об активном процессе, а с помощью команды grep указать необходимые фильтры для определения текущей системы инициализации:

Debian 11 (Testing)

Fedora 34 Workstation

Как вы можете видеть, в Debian и Fedora используется система инициализации systemd.

В случае использования системы инициализации SysV, вывод команды будет следующий:

Если же у вас используется система инициализации Upstart, то вы увидите:

Способ №2: Команда rpm

Чтобы узнать, какая система инициализации установлена, нужно выполнить следующую команду:

Примечание: /usr/sbin/init или /sbin/init — это исполняемый файл, запускающий систему инициализации SysV. По соображениям совместимости при установке systemd файл /sbin/init является псевдонимом (или символьной ссылкой) исполняемого файла системы инициализации systemd.

Fedora 34 Workstation

В случае использования системы инициализации SysV, вывод будет следующий:

В случае использования системы инициализации Upstart, вывод будет следующий:

Важное примечание

Может случиться так, что, используя ОС с systemd в качестве системы инициализации и набрав в терминале команды pidof init и pidof systemd , мы увидим следующий результат:

Debian 11 (Testing)

То есть PID=1 назначен процессу init, а процесс systemd имеет PID=909 . Получается, что у нас используется SysV? Но мы ведь уверены в том, что устанавливали дистрибутив (Debian) с системой инициализации systemd! Это можно проверить с помощью следующей команды:

$ sudo ps -p1 | grep "init\|upstart\|systemd"

Debian 11 (Testing)

Так почему же возникла путаница с pidof ? Если мы проверим тип файла /sbin/init (который является файлом, запускающим систему инициализации SysV), то увидим, что в нашем случае /sbin/init является символьной ссылкой на /lib/systemd/systemd (главный файл системы инициализации systemd):

Разжигание флейма. Погугли что ли. Тут сейчас shitstorm произойдёт, если тему не снесут.

Для десктопа, если не роллинг-релиз дистр, то пофиг. Ни разу проблем не встречал и даже не замечал, что у меня там за система инициализации.

То тебе точно не на роллинг, а, значит, не заморачивайся.

Есть мейнстримные дистры, на которых держится Linux - они все на systemd.
Есть маргинальные дистры, которые завтра умрут и никто не заметит - они все без systemd.
Есть Gentoo - это дистрибутив Шредингера. Gentoo находится в состоянии суперпозиции.

хотите ОС без systemd то ставь MX Linux а если хочешь с systemd то ставь Manjaro

наркоманы мля - из крайности в крайность… я еще могу понять такое «хотите ОС без systemd то ставь devuan а если хочешь с systemd то ставь debian»

Systemd — это система инициализации, или init. Грубо говоря, самая первая программа, которая стартует после того, как ядро ОС запустилось. Именно она и запускает все прочие программы на старте ОС.

Ранее в Linux использовался sysvinit, который был попросту набором скриптов на sh, и унаследован непосредственно от Unix System V.

Но данный init был, на взгляд многих, устаревшим, поэтому появились альтернативы:

systemd — написан на C, модульный комбайн, бинарные логи. На данный момент — самый распространенный, написан в Red Hat.

upstart — написан Canonical для Ubuntu, после 14.04 более не используется, но до сих пор развивается для Chrome OS. Могу ошибаться, но он вроде — просто надстройка над sysvinit.

openrc — написан разработчиками Gentoo для неё же на различных скриптовых языках (могу ошибаться). Более ничего не могу добавить, кроме того, что он более сложный и фичастый, чем sysvinit.

Вообще, init в Linux просто дофига. Есть ещё busybox, который популярен в embedded, runit. много.

Система, с которой я познакомлю вас сегодня, имеет огромное значение в мире Linux. Она отвечает за загрузку, управление запущенными процессами, запись и хранение логов, а также многое другое в Ubuntu и большинстве дистрибутивов, основанных на ядре Linux.

Знакомьтесь: systemd, система инициализации демонов.

Что еще за демоны?

Демоны (они же сервисы или службы) — это программы, работающие в фоновом режиме. Они не имеют графического интерфейса и даже не привязаны к конкретному окну терминала. Получив команду, они выполняют действие, для которого были созданы, а все остальное время находятся в режиме ожидания. Например, демон печати cupsd ставит в очередь документы, отправленные на печать, а затем посылает их на принтер.

Systemd используется в качестве главного демона. Во время загрузки systemd инициализирует все прочие сервисы и управляет их работой вплоть до выключения. При необходимости мы можем запустить или остановить нужный процесс, назначить или отменить его автоматический запуск или даже создать собственный сервис.

Экскурс в историю.

14 февраля 2014 года основатель дистрибутива Ubuntu Марк Шаттлворт опубликовал запись, которая всколыхнула сообщество Linux. В этой записи речь шла о том, что Ubuntu, как и многие другие дистрибутивы, переходит на систему инициализации systemd. До этого, начиная с версии 6.10, использовался менеджер служб Upstart, который, в свою очередь, сменил значительно более старый init.

Споры вокруг нововведения ведутся до сих пор.

на systemd возложено слишком уж много задач, что противоречит философии Unix;
в связи с переходом потребуется немало усилий для адаптации серверов;

Cторонники приводят свои аргументы:

Upstart морально устарела и замена была необходима;
systemd ускоряет загрузку благодаря параллельному запуску демонов;
включение в systemd дополнительных функций вроде ведения системных логов и автомонтирования делает администрирование более удобным;

Несмотря на возражения, переход состоялся, поэтому давайте разберемся с базовым использованием этой системы.

Управление сервисами через systemd.

Начнем с простой задачи — узнать, какие сервисы запущены в данный момент. Для обращения к systemd используется команда systemctl. Введя в терминал:

получим примерно следующее:

В данном случае запущено 65 сервисов.

Давайте разберем вышеприведенную команду по частям:
systemctl — обращаемся к systemd;
list-units — вывести список юнитов (в следующих статьях я объясню, что это такое);
-t — ключ, означающий, что далее мы укажем тип юнита (в нашем случае это сервис).

В списке на скриншоте присутствует cups.service. Это служба печати. Предположим, что принтера у меня нет, зато есть старый компьютер, на котором каждый запущенный сервис съедает драгоценные мегабайты памяти и замедляет загрузку. Как мне сделать так, чтобы сервис не запускался автоматически? Для этого существует команда:

Вместо cups можно подставить название любого другого демона, который вы желаете исключить из автозагрузки. При необходимости его легко можно будет вернуть командой:

Для немедленной остановки служит команда:

А для немедленного запуска:

Предположим, мне нужно проверить, запущен ли в данный момент веб-сервер Apache. Вот так это можно сделать:

Обратите внимание!
Чтобы получить информацию о запущенных сервисах, достаточно прав обычного юзера. Для выполнения каких-либо манипуляций потребуются права суперпользователя, поэтому мы действуем через sudo . Вы ведь не используете учетную запись root постоянно, не правда ли? Если все-таки да, советую покончить с этой привычкой как можно быстрее.

Хотите проверить, какие сервисы были остановлены в аварийном режиме? Пожалуйста:

В моем случае таковых нет. Кстати, совсем забыл, включил ли я Apache в автозагрузку. Давайте выясним это:

Вывод команды на скриншоте говорит о том, что apache после перезагрузки запустится самостоятельно (enabled). А также о том, что старые системы инициализации демонов оставлены в Ubuntu 16.04 (и выше) для совместимости.

Возможности systemd очень велики. В следующих статьях я покажу, как с помощью этого инструмента выключать и перезагружать компьютер, искать интересующие нас записи в логах и даже автоматизировать некоторые привычные действия.

Читайте также: