Системы инициализации на основе зависимостей -— это системы, в которых порядок инициализации служб основан на информации о зависимостях, предоставляемой внутри служб или вместе с ними. Это отличается от систем инициализации, где порядок определяется статически (, как правило, на основе лексикографического порядка, как на диаграмме, которую вы включили в свой вопрос ).

Некоторые системы могут сочетать оба подхода; например, в системах Debian, использующих sysvinit, уровень на основе зависимостей -поверх sysvinitиспользует заголовки LSB в сценариях инициализации для вычисления порядка инициализации и сохраняет его, называя символические ссылки /etc/rc?.d/соответствующим образом.

Is it the feature that distinguish it with popular SysV or Sysmted init systems?

Ну, не из systemd , которая «реализует сложную транзакционную зависимость -на основе логики управления сервисами» (акцент мой ).

Я процитирую Леннарта Поттеринга обоснование systemd здесь:

All these units can have dependencies between each other (both positive and negative, i.e. 'Requires' and 'Conflicts'): a device can have a dependency on a service, meaning that as soon as a device becomes available a certain service is started. Mounts get an implicit dependency on the device they are mounted from. Mounts also gets implicit dependencies to mounts that are their prefixes (i.e. a mount /home/lennart implicitly gets a dependency added to the mount for /home) and so on.

В старую эру sysv не существовало -первоклассного способа выражения зависимостей между системными службами. Это был ботинок -, использующий упорядочение скриптов, заголовков коммитов и тому подобное, но такая система по своей природе хрупка. Это особенно затрудняет правильное упорядочение (например, этой службе нужен этот сетевой интерфейс и эта точка монтирования, но точка монтирования требует, чтобы какое-то другое устройство было включено и т.д. -подумайте об упорядочении этого с помощью вручную, используя числовые префиксы скриптов в/etc/rcX.D/).

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

Для противопоставления и сравнения рассмотрим Upstart, который вместо прямого использования зависимостей полагался на события:

Upstart does service serialization via these events: if the syslog-started event is triggered this is used as an indication to start D-Bus since it can now make use of Syslog. And then, when dbus-started is triggered, NetworkManager is started, since it may now use D-Bus, and so on.

One could say that this way the actual logical dependency tree that exists and is understood by the admin or developer is translated and encoded into event and action rules: every logical "a needs b" rule that the administrator/developer is aware of becomes a "start a when b is started" plus "stop a when b is stopped".

«На основе зависимости -» в этом контексте означает, что он рассматривает, какие службы действительно нуждаются в функциях, предоставляемых другими службами, обычно во время выполнения и обычно без вмешательства пользователя, в отличие от того, чтобы полагаться на другие факторы для определения порядка обслуживания. запуск 9например, лексический порядок имен файлов ).

Это контрастирует с исходным механизмом инициализации SVR4, подходом init.d, использовавшимся в большинстве дистрибутивов Linux до появления systemd, и некоторыми более старыми подходами BSD rc.d, каждый из которых требует от пользователя/администратора ручного обеспечить порядок служб для запуска, либо задав имена файлов или переменные вручную, либо запустив инструмент для этого путем сканирования метаданных, встроенных в сценарии.

Примеры других систем, основанных на зависимости -, initи систем наблюдения за услугами, активно используемых сегодня, включают:

• OpenRC :Используется Alpine и Gentoo. Использует специальное определение функции и макросы в самом скрипте инициализации для получения информации о зависимостях (, которая на самом деле является довольно мощной, поскольку вы можете выразить условные зависимости между службами, такими как настройка LVM, требующая только lvmetadзапуска, если она включена в конфигурации LVM )и поддерживает «общие» зависимости (, такие как потребность в работающем демоне syslog, но безразлично, какой из них запущен ).
• Monit :Супервайзер службы, который в некоторых случаях может заменить init. Вычисляет ли зависимость во время выполнения на основе зависимостей, определенных для отслеживаемых сущностей («сущностей» вместо служб в этом случае, потому что вы можете отслеживать и зависеть от таких вещей, как внешние службы в других местах в сети или файлы и каталоги в системе, а не только услуги ).
• Upstart :Более старая замена initсистемы из Ubuntu. Upstart не отслеживал зависимости напрямую, вместо этого службы запускали изменения состояния на основе событий.который затем использовался для обеспечения того, что фактически является упорядочением запуска службы на основе зависимости -.
• Systemd :Текущий пример типа -упорядочения на основе зависимостей (часто ошибочно утверждался фанатами )как первая такая система init. Вычисляет зависимости во время выполнения и предоставляет некоторые функции, которые фактически уменьшают необходимость строгого отслеживания зависимостей в некоторых случаях.

Многие люди ошибаются. Некоторые из ответов здесь даже ошибаются.

Во-первых, давайте проясним некоторые неправильные термины:

• Различие между программой с именем init, которая выполняется как процесс #1, и программой с именем rc, которая выполняется как другой процесс, восходит к первой редакции Unix. Большая часть того, что вы обсуждаете , не выполняется процессом #1 в подавляющем большинстве программ управления службами/системами, Upstart и systemd являются исключениями , а не правилом.
• "sysvinit" не является AT&T Unix System 5 init+ rc. Это клон initи rcсистемы, изначально написанной для Minix Микелем ван Смуренбургом, по иронии судьбы через несколько лет после того, как сама AT&T Unix System 5 в значительной степени покончила с этой системой, заменив ее чем-то, называемым Service Access. Средство.

То, о чем вы спрашиваете, это управление службами , задача вышеупомянутого средства доступа к службам (SAF )в AT&T Unix, контроллер системных ресурсов AIX (SRC ), Средство управления службами Solaris (SMF ), systemd, Upstart, daemontools, daemontools -encore, runit, управление службами набора инструментов nosh, s6 и целый ряд других наборов инструментов. Первоначальная AT&T Unix System 5 rc, до того, как появились SAF и SRC, просто напрямую отделяла сервисные процессы и после этого не управляла ими.

Ван Смуренбург rcна Linux (от Minix )все еще делал это. Более того, изначально он основывался на ручном и довольно специальном порядке запуска/остановки служб по отношению друг к другу. Первоначальный гигантский единый rcшрифт, претерпевший несколько мутаций в 1970-х и начале 1980-х годов, который до сих пор можно найти окаменевшим то тут, то там (в подобных rc.local), ко времени ван Смуренбурга rcклон в 1990-х годах стал набором drop -в сценариев в подкаталоге /etc/и некоторыми фермами символических ссылок (в других подкаталогах /etc/), которые представляли порядок, в котором эти сценарии были запущены для выполнения общей задачи rc. Фермы символических ссылок были основаны на схеме приоритетов, где различным сценариям rcприсваивались приоритеты от 0 до 99. (В конце 1990-х существовал альтернативный механизм фермы символических ссылок, файл -rc, но он также использовал систему приоритетов. )Это было сложно администрировать, потому что не существовало универсальных соглашений о выборе приоритета, а также из-за проблемы «два программного обеспечения, оба хотят быть первыми». (По иронии судьбы, вы можете видеть кого-то, кто использует ископаемый способ ведения дел, спрашивая об одной из связанных проблем на этом самом сайте WWW буквально вчера.)

Управление службами на основе зависимостей -пытается работать лучше. Определения сервисов, в какой бы форме они ни были, перечисляют, какие сервисы зависят от , а должны быть упорядочены относительно при запуске и завершении работы. Нет "первого" и "последнего", но есть до и после , а также потребности и конфликты с .

Это было в системах старогоrc-стиля на Linux и BSD на протяжении большей части 21-го века.

• Mewburn rcи OpenRC (оба изобретения 21-го века )извлекли уроки из систем, которые были до них, и с самого начала включали средства выражения взаимозависимостей между различными rcскриптами. В Mewburn rcсистема комментариев в различных rcсценариях (, например. REQUIRE, PROVIDEиBEFORE)выражают взаимозависимости между службами, и программа с именем rcorderвычисляет из них порядок запуска вещей в начале каждой начальной загрузки/выключения.
• van Smoorenburg rcполучил программу под названием insservот разработчиков Debian. Взаимозависимости между службами были выражены системой обычных «заголовков LSB», включенных в качестве комментариев в различные сценарии rc, а приоритеты были переписаны в символических ссылках insservво время установки/удаления программного обеспечения, чтобы отразить зависимости. Это было довольно активно принято Debian и некоторыми его производными во второй половине первого десятилетия 21-го века. См. вики Debian для получения дополнительной информации.

Более того, он с самого начала существовал как первый -классовый механизм во многих не-rcдиспетчерах служб, от Solaris SMF до systemd. Заметными исключениями были Upstart, daemontools (и daemontools -, encore, perp и runit )и (лет назад )s6.

daemontools, runit и др. изначально все использовали подход «гигантского громоподобного стада» к проблеме, запуская и перезапуская службы снова и снова, пока все они не оставались в рабочем состоянии. Некоторые немного подправили это с помощью уловок, таких как программы, которые заставляли службы приостанавливаться и не вызывать свои основные служебные программы, пока не произойдет что-то еще, но основная идея осталась в том, что все во всем каталоге «сканирования» начиналось все в однажды.

Я долгое время утверждал, что можно было бы добиться большего, если бы над базовым управлением службами было несколько уровней,и в конечном итоге продемонстрировал это с конкретным набором инструментов, который сделал это , убрав логику запуска «сканирования» из фактического диспетчера служб, переместив ее в отдельную программу и создав систему взаимозависимостей пакетов служб вокруг базы. структуры каталогов daemontools service/supervise. Лоран Берко также продемонстрировал то же самое с дополнениями к s6, названными s6 -rc . Даже OpenRC демонстрирует это, поскольку его rcсценарии выражают взаимозависимости и могут быть использованы для использования внешнего диспетчера служб (, такого как s6 ).

Upstart, по иронии судьбы, как некоторые люди думали в 2010-х годах, на самом деле был задуман (примерно в 2005 году )как новый способ управления услугами, чтобы заменить управление службами на основе зависимости -с событием -на основе управления службами , где службы запускались в ответ на события, происходящие , а не в результате вычисления упорядоченного набора зависимостей . Обсуждение того, почему эта концепция была в конечном итоге отвергнута, и люди вернулись к управлению услугами на основе зависимостей -, выходит за рамки этого ответа, но важно понимать, что к началу зависимости 2010-х -на основе управления услугами было нормой . Разработчики-выскочки считали это старой шляпой. van Smoorenburg rcполучил это благодаря работе Debian, хотя Fedora и SUSE на самом деле не переняли это от Debian. У Mewburn rcи OpenRC она была с самого начала. systemd как раз собирались изобрести вместе с ним. Солярис, Иллумос и др. было это с SMF. И так далее.

Это не отличительная черта, за исключением подобных runit и Upstart. Это было и есть нормой. Это то, что уже делали или делали другие люди, даже при создании GNU Shepherd. GNU dmd, теперь известный как GNU Shepherd,был изобретен в 2003 году. Debian начал переход на insservв 2002 году; Ричард Гуч писал о needв 2002 году; Mewburn rcбыл изобретен в 2000 году, и в оригинальной статье Люка Мьюберна на эту тему объясняется, что выражение зависимостей с помощью чего-то лучшего, чем система приоритетов, закодированная в именах файлов, была конструктивной особенностью.

Дополнительная литература

• Джонатан де Бойн Поллард (2018 )./etc/rc.localосталось в прошлом.. Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2015 ).Известные проблемы с System 5rc. Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2018 ).Средство доступа к службам Unix. Часто задаваемые ответы.
• В.Р. (2015 -09 -05 ).История современных систем инициализации (1992–2015 гг.). darknedgy.net.