LINUX.ORG.RU

systemd — новый подход к инициализации системы

 , , , ,


2

2

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы — systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

  • Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих систем инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.

    Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.

    Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

  • Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home.

    Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

  • Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

    On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

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

    В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

  • Отслеживание процессов. В ныне используемых системах инициализации в принципе возможна такая ситуация, когда при неправильном форке процесс может «потеряться». Например, так может произойти с некорректно написанным CGI-приложением, и процесс останется работать даже после остановки веб-сервера.

    Для предотвращения таких ситуаций systemd использует интегрированный в ядро Linux механизм контрольных групп (cgroups). Если приложение не имеет доступа к псевдо-ФС, управляющей работой cgroups, то оно не может самостоятельно покинуть свою группу и «потеряться».

    Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

  • Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

  • service — обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
  • socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
  • device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
  • mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
  • automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
  • target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
  • snapshot — во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример — выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.

Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.

>>> Подробности

★★★★

Проверено: isden ()

Имхо, все (которые я видел) системы старта используют неправильный подход.

Я бы предожил такой подход:
Модули пишутся на некоем относительно высокоуровневом языке, на котором их удобно писать, который включает в себя часто используемые конструкции.
Далее все модули компилируются в исполняемый код (вероятно в С, потом в исполняемый код).
И полученный монолит выполняется при старте.
Каждый модуль отдельно может быть интерпретирован, что может быть полезно для отладки.
При хорошей реализации выше скорости достичь будет практически невозможно, есть возможности управления какими угодно зависимостями, событиями, автостартами, и прочим.

Legioner ★★★★★ ()
Ответ на: комментарий от nnz

> Но это всяко лучше того, что сейчас происходит при kill -9 1

Не разочаровывайте меня. Мы ведь прекрасно знаем, что последствия при падении init например по segfault ничем не отличаются от падения systemd от того же sigfault...

Nastishka ★★★★ ()
Ответ на: комментарий от vga

>а что не нужно - может и подождать, вплоть до проверки диска, пущай себе файлопомойка проверяется, никто не мешает залогиниться

Ага, юзер залогинился, а у него раздел с порнухой недоступен (и хорошо, если с ней). То-то будет еще криков, какой линукс хороший.

anonymous ()
Ответ на: комментарий от pevzi

С чего бы ему быть смонтированным?

Ну а про iowait - при чем здесь баги ядра, их починят, или нам теперь молиться на них и ничего нового не писать?

vga ★★ ()

+к скорости -к гибкости системы может проще ему было не писать велосипед а просто купить оффтопик?

wingrime ()
Ответ на: комментарий от anonymous

Что значит - недоступен? Опять же из прочитанного - можно сделать и доступным, а вот если он уже полезет за порнухой - то подождет, чего тут такого, желательно конечно сказать, что диск сейчас проверяется.

vga ★★ ()

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

для обучения внедрения системы на произвольные устройства и ОС требуется 10годичное обучение в бараках, с продажей собственного имущества и отдачей денег в комитет «systemd is new god»

Khades ★★ ()
Ответ на: комментарий от Legioner

IMHO все кто считает, что все остальные неправы, ошибается. Возьмеме например Вас:

Вы уже продумали объекты синхронизации для обеспечения правильной последовательности загрузки?
Научились разрешать циклические зависимости?
Продумали API для корректно реализации своего замысла?
Придумали синтаксис своего «высокоуровневого языка»?
Вот-вот :-)

Nastishka ★★★★ ()
Ответ на: комментарий от pevzi

Я же написал- файлопомойка (/media/my_cool_pr0n, может так понятнее). Корень и рут должны быть смонтированы, это ж понятно, иначе как и куда он залогинится.

vga ★★ ()

накиньте человеку скора за великолепно оформленную новость

VladimirMalyk ★★★★★ ()
Ответ на: комментарий от pevzi

Профит простой - можно в браузере полазить, на лор пописать, а потом уже в раздел с проном лезть, как проверится.

vga ★★ ()
Ответ на: комментарий от megabaks

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

vga ★★ ()
Ответ на: комментарий от madcore

> Простыню - под кат.

напиши кат - будем под него загонять...

isden ★★★★★ ()
Ответ на: комментарий от vga

>Что значит - недоступен?

Потому что не смонтирован, проверяется. На крайняк ro, но проблему это не решит.

а вот если он уже полезет за порнухой - то подождет, чего тут такого, желательно конечно сказать, что диск сейчас проверяется

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

anonymous ()
Ответ на: комментарий от BSD

> Но BSD-init наше все

Наверное, Вы опечатались, когда хотели написать «Service Control Manager и net start/net stop наше все»? :-)

Nastishka ★★★★ ()
Ответ на: комментарий от anonymous

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

Где написано, что не может? И даже если не может сейчас - то что помешает это сделать?

vga ★★ ()

новость написано классно, уважение вызывает, спасибо, аж читать приятно )

AndreyKl ★★★★★ ()
Ответ на: комментарий от vga

>А не будет сидеть и пялится на загрузку.

Вот если посидит, это поможет выработке условного рефлекса по корректному выключению. А то есть мода у некоторых, гасить системники ногой по power'у. Да и контролировать процесс проверки так надежнее, чем если оно где-то в фоне шуршит.

anonymous ()
Ответ на: комментарий от nnz

>монтировать файловые системы в фоне и имеет кучу других плюшек.

fstab.d? все десктопные костыли для автомонтирования окажутся не нужны?

thunar ★★★★★ ()
Ответ на: комментарий от bigfrogg

>Как раз в убунтах давным-давно работает Upstart, редхатовцы только сейчас начали изобретать велосипед.
Апстарт не нужен же

px ★★★ ()
Ответ на: комментарий от vga

>Где написано, что не может?

механизм управления инициализацией системы

В определении?

И даже если не может сейчас - то что помешает это сделать?

А что мешает сделать мир во всем мире? :) Тут конечно проще, но и вопрос нужности фичи не настолько очевиден.

anonymous ()
Ответ на: комментарий от anonymous

Да и контролировать процесс проверки так надежнее

Да ну. В той же бубунте рисуется прогресс бар и все. Один, большой. Что там проконтролируешь. А здесь мужик УЖЕ (первая пре-пре-альфа) написал гуевую морду со статусами и прочим. И консольный интерфейс присутствует. И изначально говорится о логировании ВСЕГО стдаут/стдерр. Так что далеко не факт, где надежнее контролируется.

vga ★★ ()

Задумка то хорошая, но боюсь выйдет как обычно: получит зачёт по курсовой и забросит проект в стадии корявой альфы (как пульсаудио).

kranky ★★★★★ ()
Ответ на: комментарий от kernelpanic

> Я вот одного понять не могу - ну вот накой все сейчас прицепились к скорости загрузки системы и решили срочно всеми силами с рвением и упорством ее уменьшать

Ноуты и нетбуки? У нас в общаге количество стационарных компов уже точно не 50%. Намного меньше. Ноут нужно бысть включить, поработать и быстро выключить

vertexua ★★★★☆ ()
Ответ на: комментарий от anonymous

В определении?

Ты таки не только определение прочитай, а и новость, желательно в оригинале. Механизмы заложены.

но и вопрос нужности

Узнаю ЛОР - так бы и написал - «не нужен!!!»

vga ★★ ()
Ответ на: комментарий от pevzi

> А можно глупый вопрос - что происходит при убийстве инита? Ни разу не пробовал (:

Убей инит

vertexua ★★★★☆ ()
Ответ на: комментарий от nnz

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

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

mikhalich ★★ ()

Ну и зачем оно нужно? У меня у десктопа по 50 дней аптайма, мне наплевать на скорость загрузки. Про сервера вообще молчу. Если человек такой нетерпеливый, и не может дождаться загрузки, то пусть не выключает комп.

anonymous ()
Ответ на: комментарий от vga

>Да ну. В той же бубунте рисуется прогресс бар и все. Один, большой. Что там проконтролируешь.

Фиговый эталон ;) Хотя да, я тоже увлекся, со своим initdefault 3.

И изначально говорится о логировании ВСЕГО стдаут/стдерр. Так что далеко не факт, где надежнее контролируется.

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

anonymous ()
Ответ на: комментарий от Casus

>А что происходит-то? А то я прямо даже не в курсе. Когда-то в исходниках ядра не постеснялся посмотреть, что процесс с номером 1 игнорирует сигнал убийства. Мои сведения устарели?

Точно, блин :)

Но когда инит убивает сам себя, ядро начинает паниковать.

nnz ★★★★ ()
Ответ на: комментарий от anonymous

> Ну и зачем оно нужно? У меня у десктопа по 50 дней аптайма, мне наплевать на скорость загрузки. Про сервера вообще молчу. Если человек такой нетерпеливый, и не может дождаться загрузки, то пусть не выключает комп.

Отучаемся думать и говорить за всех. Лично Вам не нужно - пройдите мимо новости, не флудите. Лично мне на моём личном ноутбуке нужно.

Slavaz ★★★★★ ()
Ответ на: комментарий от nnz

> // Буду благодарен, если кто-то на пальцах разъяснит мне плюшки и принцип действия init-ng.

Ничего особенного. Он правильно разруливает зависимости сервисов друг от друга (примерно как сейчас в генте) и исходя из этого выстраивает план параллельной загрузки сервисов.

anonymous ()

Quote:

AutoFS, D-Bus

Quote:

переписать критичные участки на C

Не-не-не... Это нам не надо.

GotF ★★★★★ ()
Ответ на: комментарий от Nastishka

>Я уже мысленно представила это: системный адимнистратор перенес спул сендмайла куда-нибудь на другйю файловую систему, после чего сендмайл проснулся и не нашел своего спула, ибо файловая систем «монтируется в фоне». Фантастическое и феерическое зрелище...

Насколько я понял из описания, запрос сендмейла будет получен и заблокирован в буфере, после чего сразу начнется монтирование ФС. Как только ФС смонтируется, запрос сендмейла будет обработан.

nnz ★★★★ ()
Ответ на: комментарий от EtherealPhantom

>Какой смысл быстрее загружать систему если в итоге в ней в состоянии «полностью загружена» на самом деле ничего не будет готово?

Ага. У меня до сих пор стоит перед глазами моя предыдущая винда, которая после загрузки еще минимум минут 15 или даже 20 была тупо не юзабельна. Не знаю, чем она там занималась, но до прекращения моргания свопом я ей предпочитал не пользоваться. Так, загрузил винду и ушел на кухню чай себе готовить.

Оттого то я и смотрю, что бенчмарки скорости загрузки разных ОС в последнее время все чаще проводятся не замером времени до появления десктопа (чем и меряются обычно), а до достижения состояния «покоя процессора».

YogSagot ★★ ()
Ответ на: комментарий от thunar

>это значит на XMLе через гномереестр?

Это в солярисе сейчас так.

В systemd обещают сделать конфиги в старом добром формате INI (или, как они это называют, .desktop).

nnz ★★★★ ()
Ответ на: комментарий от vga

>Ты таки не только определение прочитай, а и новость, желательно в оригинале. Механизмы заложены.

То, что заложено, само задачу полностью не решит же. И не должно.

так бы и написал - «не нужен!!!»

Ощути разницу ;)

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.