LINUX.ORG.RU

Systemd 29

 , ,


0

1

16 июня, тихо и незаметно вышла 29-ая версия новой системы инициализации для Linux. Среди её возможностей основными являются:

  • событийно-ориентированная система параллельного запуска сервисов;
  • управление через dbus;
  • упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C для управления консолью, установки локали, запуска fsck, монтирования файловых систем и др.;
  • возможность запуска сервисов по появлению данных в сокете, запуску или остановке других сервисов, наличию подключённых устройств или смонтированных файловых систем;
  • встроенное упреждающее чтение с диска;
  • интеграция с cgroups;
  • совместимость со старыми скриптами, предназначенных для использования с SysVinit.

Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

В новой версии были незначительно изменены Makefile-ы, и было добавлено 2 пункта в TODO:

  • посылать сигнал, когда загрузка завершена;
  • при неудачном запуске сервиса попытаться перезапустить его.

Будем надеяться, что в следующей 30 версии мы увидим эти новые фичи.

Исходники

О systemd и ссылки

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

★★★★★

Проверено: maxcom ()
Последнее исправление: gentoo_root (всего исправлений: 1)

Ответ на: комментарий от gentoo_root

> systemd такое легко без скриптов и костылей может.

Это потому, что systemd включает в себя эти костыли (и еще много других).

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

>Гипотетический проход по списку останавливается до окончания запуска local_fs, потом - до окончания запуска network, потом пускает в параллель serv1 и serv2,

Хехе - а serv1 зависит от serv2 и они гипотетически запускаются друг за другом :) Не - в некоторых случаях это даже даст какой-то выигрышь :)

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

> Хехе - а serv1 зависит от serv2

Хехе, это ты сам только что придумал. В моем примере они не зависят.

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

> И как ты представляешь при таком раскладе за один проход запустить паралльно процессы с взависимостями ?

Порядок их просмотра задан их именами. Никаких проблем нет. Просто смотрим сверху вниз список из /etc/rc2.d/S* вида:

S00localfs
S10iptables
S15network
S20syslog
S25remotefs
S30dbus
S40sshd
S50vsftpd
S60httpd
...
Для каждого файла читаем LSB Header и проверяем, если среди исполняющихся или находящихся в очереди сервисов есть тот, от которой зависит этот сервис, то ставим его в очередь на ожидание, если нет - запускаем сразу. Так до тех пор, пока не пройдем по всем файлам. Один проход. Никаких циклов.

В приведенном выше примере запуск будет выглядеть так:

S00localfs
S10iptables  S15network
S20syslog  S25remotefs
S30dbus S40sshd S50vsftpd S60httpd
...

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

> Ясно, без костылей на баше нельзя. А systemd такое легко без скриптов и костылей может.

А systemd такое делает либо таким же скриптом, либо с собственным костылем. Я уже спрашивал раньше по треду как сделать монтирование... Костылей в ответе было в два раза больше. У systemd полный /lib этих костылей, а некоторые еще засунуты в /bin и /usr/bin.

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

Обычный шелл, в который встроены команды вроде grep и cut.

Scheme shell спасёт отца прусской демократии.

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

весь интернет дружно сказал «НАХ!».

Ты ошибаешься. Фанатиков в сети много, но на «весь интернет» они не потянут.

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

>Я уже спрашивал раньше по треду как сделать монтирование...

Это там, где шифрованный раздел? Разработчик почему-то посчитал ненужной опцию ExecStartPre= или аналогичную в юнитах-маунтах. Поэтому было:

Костылей в ответе было в два раза больше.

У systemd полный /lib этих костылей

Когда это всё в одной программе, это не костыли.

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

Так тут S50vsftpd S60httpd можно было запускать вместе с S10iptables S15network а у тебя они ждут ненужные сервисы, а вдруг они по 30 минут запускаются ?

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

> А теперь представь - что твой скрипт уже давно обошел список за время пока поднимался net и оба serv1 и 2 оказались в очереди, как они оттуда параллельно запустятся при одном проходе ?

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

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

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

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

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

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

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

>Так тут S50vsftpd S60httpd можно было запускать вместе с S10iptables S15network?

Нельзя. S50vsftpd и S60httpd не могут запускаться параллельно с S10iptables, потому что иначе есть риск поймать момент, когда S50vsftpd запустился, а S10iptables еще нет, и мы получим доступ к ftp-серверу в обход файрвола. Это недопустимо. Но без явных зависимостей ты бы этого не узнал. Зависимости рулят. :)

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

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

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

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

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

>Такая система, с одной стороны, полностью обратносовместима с sysvinit, не добавляет ни единой новой сущности, и не ломает ни одной существующей утилиты.

Один проход был по списку файлов в rc.d для того, чтобы сформировать очередь...

bla-bla-bla. Дерзай, 3.14здеть не мешки ворочать.

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

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

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

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

Такой изврат намного хуже элегантного systemd :-)

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

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

Людям, от которых зависит, попадет ли программа в дистрибутив, это не пофиг // К.О.

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

tailgunner

Людям, от которых зависит,

Т.е. ты уже не говоришь за всю сеть? Это хорошо.

tailgunner

попадет ли программа в дистрибутив

Не все мантейнеры --- фанатики. По крайней мере не во всех дистрибутивах.

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

> Когда это всё в одной программе, это не костыли.

Да сколько же можно повторять. Когда все в одной программе - сама программа становися костылем. Вроде, всем очевидно, что объединять httpd, gdm, udev и git в одном демоне - это маразм. Так почему же так хочется объединить init, xinetd, udev, atd и dbus в одном systemd? (что dbus еще не в systemd? ничего, будет...)

Разные программы обслуживают разные задачи. init-демон обслуживает запуск системы и только его, демон udev обслуживает устройства и только их, xinetd обслуживает сокеты, только сокеты, а atd обслуживает только запуск по времени. У них разные задачи. Строго разные. Не пересекающиеся ни в одной точке.

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

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

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

Ничего не напоминает?

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

> Дерзай, 3.14здеть не мешки ворочать.

Уже подумываю об этом. Надо лишь убедиться, что этого еще никто не сделал, чтобы не стать очередным Леннартом. К тому же всегда интересно послушать конструктивную критику на ЛОРе...

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

> Напоминает - X Windows ;-)

Кто из разрабов X Window System переписывал существующие библиотеки, а потом уговаривал других перейти на их использование? И что это были за библиотеки?

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

> Такой изврат намного хуже элегантного systemd :-)

«Такой изврат» - это почти строгое доказательство корректности системы. Это не реализация, и даже не намек на нее, это формальная математическая логика. «Элегантный systemd» лучше логики? Хотя, в чем-то это верно. Логики в systemd не наблюдается. :)

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

>Кто из разрабов X Window System переписывал существующие библиотеки, а потом уговаривал других перейти на их использование? И что это были за библиотеки?

Я лично не знаком с разработчиками - но то что там счас творится - это большая куча медленного навоза которая как побочное явление умеет еще что то рисовать на экране ;-)

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

> *** ugoday уходит судорожно искать слово «значимый» во фразе:

Ах да, еще я не имел в виду, что роутеры умеют говорить %)

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

>Уже подумываю об этом.

Бесполезно. Даже если твоя поделка будет в 100 раз лучше, всё равно будут юзать леннартовские костыли. И пропихивать их во все дистры.

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

Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата. Есть один на примете, но он в отпуск уехал.

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

> Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата.

Тогда объясняю простым языком, специально для лиспотроллей: если бы systemd был написан на Лиспе, его бы не запихивали в дистры с такой силой. Если бы он еще и требовал писать юниты на Лиспе, его вообще можно было бы не принимать во внимание.

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

>Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата.

ugoday

Юзернейм как бы намекает ;)

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

Тогда объясняю простым языком

Другой разговор, гораздо лучше чем загадки и полунамёки.

если бы systemd был написан на Лиспе, его бы не запихивали в дистры с такой силой

Странное утверждение, а главное --- обоснованное.

писать юниты на Лиспе

юниты на С это конечно гораздо-гораздо лучше.

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

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

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

> юниты на С это конечно гораздо-гораздо лучше.

Ага. Си знает больше народу. Впрочем, «юниты на Си» - это, насколько я могу судить, миф.

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

>http://wiki.debian.org

Кстати - а откуда идут мифы о стабильности дебиана ? В последний раз когда мне нужно было ставить что-то дебианоподобное я выбрал убунту - потому что установилась она без проблем. Я сначала купился на мифы и начал с дебиана - на обоих ноутбуках дебиан не установился - это был образ netinstall версии 5.06. Он долго качал пакеты устанавливал а в конце зависал намертво, после перезагрузки была нерабочая система. Такие дела.

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

> Кстати - а откуда идут мифы о стабильности дебиана ?

От людей, у которых он стабильно работает.

начал с дебиана - на обоих ноутбуках дебиан не установился - это был образ netinstall версии 5.06. Он долго качал пакеты устанавливал а в конце зависал намертво, после перезагрузки была нерабочая система. Такие дела.

Не понравился ты Дебиану. Видно, не крепок ты в вере. Молись Столлману, донейти свободному софту - может, и понравишься ты Дебиану, и установится он на твои ноуты.

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

>Вроде, всем очевидно, что объединять httpd, gdm, udev и git в одном демоне - это маразм. Так почему же так хочется объединить init, xinetd, udev, atd и dbus в одном systemd?

Ты мне лучше скажи, а какого чёрта команды pidof и mountpoint делают в пакете sys-apps/sysvinit? Какая связь init, pidof и mountpoint, что их запаковали в 1 пакет? Это такой же маразм, как «объединять httpd, gdm, udev и git в одном демоне».

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

Си знает больше народу

Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

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

> Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

Да понятно... у лисперов и должны быть всякие прикольные фобии.

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

>Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

А я боюсь если бы их писали на липсе - загрузка до сих бы только до процесса init доходила ;-)

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

>какого чёрта команды pidof и mountpoint делают в пакете sys-apps/sysvinit?
Этот вопрос нужно задавать ментейнерам твоего дистрибутива.

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

>В Debian pidof в sysvinit-utils, mountpoint - в initscripts.

sysvinit-utils собирается из исходников sysvinit. В дебиане любят разбивать один пакет на много кусков.

Но факт в том, что если взять апстримовые исходники SysVinit, собрать и установить, то pidof и mountpoint таки в пакете вместе с init. Значит, SysVinit объединяет в себе совершенно несвязанные программы. Как сказал анонимус, «объединять httpd, gdm, udev и git в одном демоне - это маразм». Объединять pidof, mountpoint и init в одном пакете - это тоже маразм. Так что этот ваш святой SysVinit ещё хуже, чем вы себе представляете systemd. В systemd хоть прослеживается связь между компонентами, а какая в SysVinit связь между pidof, mountpoint и init?

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