Systemd 29

интеграция с cgroups

Отличная новость.

>>интеграция с cgroups

Отличная новость.

Что-то не так? В systemd есть автоматическая группировка процессов на основе cgroups. Она ещё конфликтует с аналогичной системой, появившейся в 2.6.38 ядре.

Что, я похож на тролля?
Я так понял что как раз эту проблему пофиксили, и это хорошо.

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

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

> событийно-ориентированная система запуска сервисов с параллельным запуском демонов;

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

управление через dbus

Где теги [закопать][не нужно][xml головного мозга]?

упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C

В чью-то голову вдруг пришла идея писать скрипты на Си, за окном неспешно шел XXI век...

интеграция с cgroups

Слоупоки такие слоупоки.

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

Просто поразительно, особенно если учитывать, что всё это прекрасно делается без сабжа.

> упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C

Наконец-то хоть кто-то осуществил этот шаг. А то все только и горазды кричать, что скрипты (sh/python/perl) для быстрого proof-of-concept, а потом надо переписывать на нормальные языки, но до переписывания так и не доходило.

>Это какой-то сферический в вакууме сервер занимающийся ничем

Это мой нетбук.

>В чью-то голову вдруг пришла идея писать скрипты на Си,

Там не скрипты, а скомпиленные программы.

http://0pointer.de/blog/projects/systemd.html

Читать отсюда:

Keeping the First User PID Small

Просто поразительно, особенно если учитывать, что всё это прекрасно делается без сабжа.

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

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

Исправлю.

>Это мой нетбук.

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

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

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

>Я бы тогда уточнил юзкейс. Далеко не со всяким набором сервисов можно так быстро погасить свет.

У меня там дефолтнейший набор из udev, dbus, NetworkManager, gdm, syslog-ng и всяких ConsoleKit и PolicyKit, которые грузятся сами. А при нажатии на «Выключить» в гноме systemd просто рассылает всем процессам сигналы, иксы вырубаются около секунды, потом почти мгновенно (порядка 0,2 секунды) размонтируются ФС и выключается. Но в арче был какой-то глюк, связанный с тем, что syslog-ng не выключался, поэтому часто выключение зависало на 3 минуты. В Генте не встречал этого бага.

Чем он лучше OpenRC?

> http://0pointer.de/blog/projects/systemd.html

Таки там отлично описано, что проблема не со скриптами, а с большим количеством процессов, которые приходится запускать из них. Абсолютно не понятно, что мешало разрабу взять для скриптов любой язык, не требующий порождения отдельного процесса на каждый чих: Tcl, Io, Lisp, JS, тысячи их. Писать в XXI веке высокоуровневую загрузочную логику на Си — это надо иметь поражение мозга, чтобы до такого додуматься.

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

Чтобы загрузиться до графического логина на среднестатистическом десктопе, нужно:
* прогнать инициализирующие события по udev
* смонтировать файловые системы
* поднять сислог
* поднять dbus
* поднять *dm с иксами.
Всё.

Хоть тресни, а быстрее в иксы не попадёшь.

ФС не проверять

Если не проверять, станешь ССЗБ. А проверять из надо до того, как на них что-нибудь запишется. Так что раз в N загрузок задержка старта будет под какой угодно системой инициализации.

шрифты и кеймапы не устанавливать

Или же устанавливать после запуска *dm. И все остальные службы запускать тоже.

> Писать в XXI веке высокоуровневую загрузочную логику на Си — это надо иметь поражение мозга, чтобы до такого додуматься.

+1, лютая жесть. «I wrote most of Avahi and PulseAudio, among other stuff. Right now I am focusing on systemd which I created» Как много зла может принести миру всего лишь один человек :(

Еще добавлю:

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

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

В общем гном за 10 секунд — не абы какое важное достижение. Это наверное с ssd?

>Avahi and PulseAudio

Avahi то чем не угодил? ALSA с dmix тоже никто не отменял, пульсу никогда не использовал, но вещь определенно полезная.

> прогнать инициализирующие события по udev

Не нужно. Можно запускать сервисы по мере активации устройств, что и делает systemd.

поднять сислог

Тоже не критичен.

И это можно делать одновременно, что и делает systemd.

>за окном неспешно шел XXI век...

Вы таки предлагаете переписать наконец на моно?

>JS

Как раз можно было бы линупс и закопать.

> Десктоп, увязший по колено в свопе, тоже по щелчку пальцев не потухнет.

У меня нет свопа. И прокси-сервера на нетбуке.

Это наверное с ssd?

Нет, обычный винт.

про пульсу не согласен, с остальным согласен. Мой арч до инит3 загружается за 4 секунды, без всяких системД или ССД-дисков. И кеды ещё секунд 15-20 секунд.

> Не нужно. Можно запускать сервисы по мере активации устройств, что и делает systemd.

Ага. Запустить иксы до инициализации ядерного видеодрайвера. Фантастика на грани техники.

И это можно делать одновременно, что и делает systemd.

Монтировать /var одновременно с записью данных туда? :D

одновременно

У меня система без всякого systemd пускает одновременно демоны, которые возможно так запустить. Что я делаю не так?

>> поднять сислог

Тоже не критичен.

Бгг.

Пульса у меня звук по сети гоняет. А вот остальное действительно зло.

>Запустить иксы до инициализации ядерного видеодрайвера.

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

С обычным инитом сначала udev проинициализирует все устройства, потом начнут запускаться демоны.

Монтировать /var

Только очень суровые ССЗБ так делают.

А чем оно лучше Upstart?

при неудачном запуске сервиса

попытаться перезапустить его.

A в Upstart respawn давно есть.

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

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

инициализации сети

Путаем втыкание драйвера на сетевой интерфейс и реальную инициализацию сети с назначением адресов и другими магическими обрядами?

> Монтировать /var

Только очень суровые ССЗБ так делают.

В общем-то, всё ясно. Ну значит, вы как раз целевая аудитория для systemd. Больше вопросов не имею.

> событийно-ориентированная система параллельного запуска сервисов

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

управление через dbus

У init-а? 0_о А кто запустит dbus чтобы дать команду init-у запустить dbus? А если dbus убить - init уведет систему в kernel panic? Нафиг!

замена схожим по функциональности кодом на C ...

То есть теперь, чтобы добавить в pre-boot монтирование собственных каталогов нужно не поправить несколько строк скрипта, а пересобрать init-демон? Какой идиот это придумал?

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

Не нужно в init-е, есть xinetd, это его работа.

наличию подключённых устройств или смонтированных файловых систем

Тоже не нужно в init-е. Есть udevd и udisks.

встроенное упреждающее чтение с диска

Внезапно, readahead.

интеграция с cgroups

Не нужно в init-е. Есть ulatencyd.

совместимость со старыми скриптами, предназначенных для использования с SysVinit

Хрен там, а не совместимость. Юзеры Fedora15 это хорошо почувствовали на себе.

ВЫВОД: НЕ НУЖЕН! ЗАКОПАТЬ!

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

О да, это был эпик баг, когда systemd снимал питание раньше, чем ядро успевало отмонтировать файловые системы. Кстати, его уже поправили? Или fsck до сих пор после выключения в systemd ругается «filesystem is NOT clean»?

> Я так понял что как раз эту проблему пофиксили, и это хорошо.

Нихрена там не пофиксили. systemd при старте отключает эту фичу в ядре и использует собственную группировку. ulatencyd в свою очередь, если детектит, что он запущен вместе с systemd, отключает cgroups у себя и работает на порядок хуже.

>Только очень суровые ССЗБ так делают.
Что, /run ещё нет, а systemd уже хочется?

Хороший, годный анонимус в треде. Всё правильно написал.

Что только люди не делают, лишь бы на init-ng не переходить.

Чем примечательна 29-я версия? Их выпускают довольно часто.

>У меня нет свопа. И прокси-сервера на нетбуке.

Ну вам, в принципе, выше уже прямым текстом сказали о том, на что я намекаю.

Нет, обычный винт.

Быстро.

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

Такое ощущение, что редхату больше делать нечего, кроме как пропихивать поделки этого дарования.

ЗЫЖ а за автоматический перезапуск упавших сервисов надо сразу расстреливать. Даже в венде до такого не додумались, кажется.

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

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

Конечно. Но лучше на Java. А исполнять на Java-процессоре.

>А кто запустит dbus чтобы дать команду init-у запустить dbus?

systemd же и запустит, когда надо будет.

А если dbus убить - init уведет систему в kernel panic?

Может, ещё и rm -rf --no-preserve-root / сделает? Перезапустит и делов-то.

чтобы добавить в pre-boot монтирование собственных каталогов нужно не поправить несколько строк скрипта, а пересобрать init-демон?

Поправить скрипт - это костыль. Для монтирования есть /etc/fstab. systemd его прекрасно понимает.

наличию подключённых устройств или смонтированных файловых систем

Есть udevd и udisks.

Они и скажут init'у, что «появился такой-то bluetooth-адаптер», а systemd же запустит bluetoothd. Или «появился раздел жёсткого диска», systemd увидит, что в /etc/fstab в последней колонке напротив него не 0, скажет systemd-fsck, чтобы тот запустил fsck.

Не нужно в init-е, есть xinetd, это его работа.

Внезапно, readahead.

Не нужно в init-е. Есть ulatencyd.

Зачем куча костылей, если есть всё в одном флаконе?

>О да, это был эпик баг, когда systemd снимал питание раньше, чем ядро успевало отмонтировать файловые системы.

К счастью, я с этим багом не столкнулся.

Что, /run ещё нет, а systemd уже хочется?

max@laptop ~ $ ls -l /run/
итого 28
drwxrwxr-x 2 root root   60 Июн 17 21:41 console
drwxr-xr-x 2 root root   80 Июн 17 21:41 ConsoleKit
drwxr-xr-x 2 root root   60 Июн 17 21:41 dbus
-rw-r--r-- 1 root root    4 Июн 17 21:41 dbus.pid
drwx--x--x 4 root gdm    80 Июн 17 21:41 gdm
-rw-r--r-- 1 root root    4 Июн 17 21:41 gdm.pid
drwxrwxr-x 5 root root  100 Июн 17 21:42 pm-utils
-rw-r--r-- 1 root root    5 Июн 17 22:09 ppp0.pid
-rw-r--r-- 1 root root 8192 Июн 17 22:09 pppd2.tdb
srw-rw-rw- 1 root root    0 Июн 17 21:41 sdp
srwxrwxr-x 1 root root    0 Июн 17 21:41 syslog-ng.ctl
-rw-rw-r-- 1 root root    4 Июн 17 21:41 syslog-ng.pid
drwxr-xr-x 4 root root  160 Июн 17 21:41 systemd
drwxr-xr-x 7 root root  160 Июн 17 22:11 udev
drwxr-xr-x 2 root root   40 Июн 17 21:41 user
-rw-rw-r-- 1 root utmp 3456 Июн 17 21:41 utmp
max@laptop ~ $ ls -l /var/run/
итого 28
drwxrwxr-x 2 root root   60 Июн 17 21:41 console
drwxr-xr-x 2 root root   80 Июн 17 21:41 ConsoleKit
drwxr-xr-x 2 root root   60 Июн 17 21:41 dbus
-rw-r--r-- 1 root root    4 Июн 17 21:41 dbus.pid
drwx--x--x 4 root gdm    80 Июн 17 21:41 gdm
-rw-r--r-- 1 root root    4 Июн 17 21:41 gdm.pid
drwxrwxr-x 5 root root  100 Июн 17 21:42 pm-utils
-rw-r--r-- 1 root root    5 Июн 17 22:09 ppp0.pid
-rw-r--r-- 1 root root 8192 Июн 17 22:09 pppd2.tdb
srw-rw-rw- 1 root root    0 Июн 17 21:41 sdp
srwxrwxr-x 1 root root    0 Июн 17 21:41 syslog-ng.ctl
-rw-rw-r-- 1 root root    4 Июн 17 21:41 syslog-ng.pid
drwxr-xr-x 4 root root  160 Июн 17 21:41 systemd
drwxr-xr-x 7 root root  160 Июн 17 22:11 udev
drwxr-xr-x 2 root root   40 Июн 17 21:41 user
-rw-rw-r-- 1 root utmp 3456 Июн 17 21:41 utmp
max@laptop ~ $ mount | grep '/run'
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

Внезапно, пора бы уже вылезти из криокамеры. /run давно есть, а /var/run смонтирован как bind /run'а для обратной совместимости.

>Чем он лучше OpenRC?

В OpenRC нет практически никаких фич, которые имеет systemd. И на моём нетбуке он грузил за 30 секунд, что недопустимо.

>А чем оно лучше Upstart?

http://www.opennet.ru/opennews/art.shtml?num=30412

Вот сравнение.

A в Upstart respawn давно есть.

В SysVinit тоже есть. Он респавнит getty.

>Что только люди не делают, лишь бы на init-ng не переходить.

Хотел перейти ещё до появления systemd. Но выяснилось, что его давно забросили.

>Чем примечательна 29-я версия? Их выпускают довольно часто.

Я сделал diff 28 и 29, там ничего особенного нет. Нового кода нет, небольшие изменения Makefile'ов, добавлено 2 пункта в TODO.

>> А чем оно лучше Upstart?

http://www.opennet.ru/opennews/art.shtml?num=30412

Вот сравнение.

И что, это всё уже реализовано, или то что будет?

Пока его версия не достигнет как минимум v1.1, дистры с этой ситемой лучше избегать ИМХО

> Перезапустит и делов-то.

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

Поправить скрипт - это костыль. Для монтирования есть /etc/fstab. systemd его прекрасно понимает.

Во-первых, он его понимает криво. Небольшое отступление от формата или нестандартное имя NFS-раздела подвешивают загрузку на 10 минут. Во-вторых, костыль - это запихивать в systemd функции mount-а, а правка скрипта - это решение задачи.

Предположим, я хочу оставить корень и /usr в read-only. Пусть, например, это - дополнительная защита сервера. Или, может, у меня SSD-диск и я хочу избежать лишних операций записи. Для этого мне нужно выполнить несколько действий, смонтировать некоторые каталоги в tmpfs или mount-bind-ом на другие разделы. Если этого не сделать - система не запустится. И этого нельзя сделать из fstab-а, потому что mtab - тоже находится на корне, и в него тоже не должна выполняться запись, корень вообще не должен становиться rw.

Сейчас я могу это сделать, изменив несколько скриптов в /etc/rc*, потому что это - обычные скрипты на баше. А что мне делать с кодом на С? Перекомпилировать каждый раз, когда я хочу что-то изменить?

Они и скажут init'у, что «появился такой-то bluetooth-адаптер», а systemd же запустит bluetoothd.

И зачем для этого systemd? udev отлично выполняет запуск программ при появлении устройств. Так много лет работает usb_modeswitch.

Или «появился раздел жёсткого диска», systemd увидит, что в /etc/fstab в последней колонке напротив него не 0, скажет systemd-fsck, чтобы тот запустил fsck.

А если я этого не хочу? А если это - битая флешка, и мне нужно восстановить с нее файлы, а fsck добьет то, что там осталось? Если в fstab-е было noauto, значит никаких действий быть не должно, и точка. Если не было - он должен монтироваться и проверяться при загрузке. Не надо решать за меня, что мне нужно. Система должна делать то, что ей сказано. Это - не винда. Я не должен каждый раз угадывать, что на этот раз может произойти.

Кстати, был и такой баг в systemd, он монтировал даже то, что отмечено noauto. Это исправили?

> Зачем куча костылей, если есть всё в одном флаконе?

Неужели надо объяснять основы unix? «Write programs that do one thing and do it well.» Когда есть отдельные программы для каждой задачи - есть выбор, я могу их комбинировать и настраивать как мне нужно. Когда есть одна программа, которая пытается делать все, я связан возможностями и глюками этой одной программы.

Два варианта: нормальный init+dbus+xinetd+udev+readahead+ulatencyd против systemd все-в-одном.

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

Когда-то был devfs, потом ему на смену пришел udev, если через два года придет newdevd, то в первом варианте его можно будет заменить, а остальные компоненты будут работать, во втором варианте жесткая зависимость от udev сделает систему незагружающейся вообще.

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

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

Пока init-демон являлся маленькой пускалкой bash-скриптов - все было замечательно. Даже если что-то не так - всегда можно открыть скрипты и легко найти ошибку или исправить проблему. Но когда проблема - внутри systemd, то чем исправить ее, легче признать ошибку фичей, что Леннарт обычно и делает. А ошибки в systemd еще править и править. `shutdown -h 10m` когда заработает?

На данный момент мы имеем: критически важный для системы init-демон не имеет ни прямой ни обратной совместимости, содержит море ошибок и вызывает кучу проблем, а в перспективе, зная любовь Леннарта к виндоподобным монстрам, он будет создавать этих проблем еще больше. При этом заставляет отказаться от кучи возможностей, которые были раньше, и не дает НИ ОДНОЙ НОВОЙ возможности взамен. Втопку такой init.

Леннарт хоть раз писал что-то, что работало из коробки?