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 ()

Ошибка: слишком большое сообщение

systemd в настоящее время находится в состоянии активной разработки, однако уже существует рабочий прототип. В частности, через BitTorrent вы можете скачать QEMU-образ виртуальной машины, с установленной на ней Fedora 13 и интегрированным systemd. Также вы можете ознакомиться с исходным кодом проекта.

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

>Для адекватного сравнения интересно было бы узнать и недостатки этого механизма.

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

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

>чем оно лучше init-ng? быстрее?

Лично я init-ng не ковырял, но полагаю, что он работает во многом аналогично выскочке. Ну а в тексте новости я уже кратко пояснил, почему systemd должен быть быстрее этой схемы. Подробный сравнительный анализ выскочки и systemd можно почитать по ссылке.

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

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

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

> Ждем в Дебиане... (плача) ...через года 3...

Не ждем. Ибо не нужно.

tailgunner ★★★★★ ()

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

А не помешает ли это самостоятельному написанию init-скриптов?

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

>А не помешает ли это самостоятельному написанию init-скриптов?

Вообще Леннарт какбэ намекает, что init-скрипты — жуткие тормоза, моветон и не по-пацански. И вообще индусский код.

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

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

> Вообще Леннарт какбэ намекает, что init-скрипты — жуткие тормоза, моветон и не по-пацански.

30 лет init-скрипты работали и всех устраивали, но в 2010 году ВНЕЗАПНО шелл и греп стали тормозить.

И вообще индусский код.

Да, от создателя PulseAudio это звучит особенно убедительно.

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

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

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

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

Я тоже этого не понимаю :)

Но, как видно из описания, это не просто «еще одна ускорялка загрузки». Это, по сути, демон, централизованно управляющий всей системой. Кроме того, там обещают достаточно крутой функционал по части безопасности. И простые конфиги :)

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

>Падает один демон systemd - падают все, или как?

Как раз нет. В описании сказано, что его тоже можно перезапускать, и никто ничего не заметит. Например, при обновлении системы на лету. Насчет конкретно падений не в курсе.
Но это всяко лучше того, что сейчас происходит при kill -9 1 :)

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

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

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

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

Советую почитать «войну и мир» по ссылке. Имхо, оно того стоит.

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

nnz ★★★★ ()

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

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

важное?
этож квадратно-колесных_велосипедо-строи^Wpulse-о создатель ваяет
народ волнуется )

megabaks ★★★★ ()

интересная штука, правда все эти радости, такие как замену крона в upstart обещали еще в далеком 2006, но до сих пор их и близко нет

HighwayStar ★★★★★ ()

В принципе позитивно, но несколько смущает, что Linux (как впрочем и любая другая крупная система) со временем начинает всё больше и больше усложняться. Впрочем, у нас всегда есть в запасе Slackware ;)

runtime ★★★ ()

Хорошо описал новость!

Есть правда НО: не описана первичная область применения, а она почему-то ускользает от anonymous-ов :)

Такая вещь в первую очередь востребована в облачных вычислениях, когда на какой-нибудь мейнфрейм приходит заказ на старт пару десятков узлов. Такая система будет готова к работе куда быстрей чем с сегодняшним SystemV init. И даже с Upstart. Какой-нибудь sendmail etc. может и подождать стартовать.


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

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

а что еще делать, когда в Линуксе уже все работает ?

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

>а что еще делать, когда в Линуксе уже все работает ?
писать то, чего не хватает обычным пользователям, не?
ПРОСТОЙ видео редактор, например :)

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

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

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

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

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

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

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

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

> писать то, чего не хватает обычным пользователям, не?

... ПРОСТОЙ видео редактор, например :)

Да, ещё «обычному пользователю» нужен фотошоп, микрософт ворд...

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

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

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

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

>Да, ещё «обычному пользователю» нужен фотошоп, микрософт ворд...
думай для начала!
и худей!
фотоопа простого пользователя ни разу не улыбает!
а ворд...простому пользователю за глаза хватает abiword-а!

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

> Да, ещё «обычному пользователю» нужен фотошоп, микрософт ворд...

... автокад; а как файнридер простому пользователю нужен - просто не передать словами...

Slavaz ★★★★★ ()

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

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

>Какой смысл...?
дык...это...вендо стайл!
пользователю понятней и роднее - они нашли ключ к сердцам масс ^_^

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

воооот - допилить надо, а то лисапедов развели
да и автор сабжа тот ещё велосипедист, да ещё и с «золотыми» руками )

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

> kill -9 1

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

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

Кунейформ ня. А автокад простому пользователю уж точно не нужен, извините (:

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

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

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

тренд сейчас такой. Да и меряться этим можно :)

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

Писать в багзиллу, ждать апдейтов.. Как с большинством прог.

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

> А если в его магическом init на C баг ?

Не «если», а «сколько» и «насколько критичных» :)

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

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

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

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

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

*шепотом* iowait.

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

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

Потому что, в отличие от всего остального, системы инициализации независимы от системы. Их можно вырывать и вставлять новые не затрагивая ни одного демона или приложения - в отлчие от тех же X'ов, где нужно обеспечить совместимость по протоколу, совместимость с дарйверами и много чего еще. В общем, «ищем где светло». Писать новые приложения трудозатратно, а написать еще-одну-самую-лучшую-систему-инициализации можно быстро и чуть не в одиночку.

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