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

Вендо стайл же. Скорее показать dm, всё остальное подождет.

Параллелизация. Обычные системы грузят сервисы подряд, а система д одновременно почти все.

Никакой магии. Инитскрипты у меня грузились за ровно столько же. Просто lxdm ближе к началу списка демонов поставить, и получится всё то же самое.

Зависимости, параллелизация, активация по требованию.

Параллелизация.

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

Скорее показать dm, всё остальное подождет

systemd так не делает (вернее, делает, но не совсем так), а вот в варианте geekless как раз так и есть.

Рассказывай тут сказки, ага. Мой арчег на допотопных скриптах грузился быстрее. А всё почему? Потому что dm'а нет, wow эффект вызывать нечем.

В openrc есть опция с подозрительнымназванием rc_parallel

Зависимости, параллелизация, активация по требованию

Все это есть и так. По крайней мере в Gentoo.

Нет, именно отложенный запуск

Что это?

В openrc я засовывал kdm в уровень boot и он появлялся уже спустя две-три секунды после груба. Только зачем это нужно, я не очень понял.

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

Есть, но она не очень стабильно работает и не рекомендуется.

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

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

Так это к systemd претензии. В openrc все нужные демоны в наличии.

В квотезы!

активация по требованию

Все это есть и так

ORLY?

Мой арчег на допотопных скриптах грузился быстрее

А мой — нет. И DM показывается в конце загрузки, после него стартует разве что автомонтирование /home.

М-да. То есть если учесть в openrc есть паралельная загрузка и отбросить принцип появление GUI до загрузки всего остального - никто не знает что делает systemd!!!. Катимся ли мы в идиократию???

То есть, ты утверждаешь, что последовательный systemd будет так же быстр?

Почитай арчвики — там хорошо описано как сделать все это. У меня в таком конфиге (hdd) грузилось за 11 секунд

DAEMONS=( \
    syslog-ng dbus \
    @acpid @crond @laptop-mode @alsa @preload \
    @arno-iptables-firewall @wicd @ntpd \
    @transmissiond @tor @i2prouter @emacsd \
)

Без него это тоже делается.

Что такого там в этом systemd, что оно позволяет делать загрузку за несколько секунд?

В самом systemd — ничего. Любая система загрузится за несколько секунд, если отключить практически все.

Как это работает?

Также, как и в других системах инициализации.

И почему обычной системой инициализации это не делается?

Делается, просто Поттеринг умеет в рекламу.

Открывайте исходник и вперёд, правда он теперь совмещён с исходником udev, ну что поделать.

Или у Поттеринга спросите.

И система после старта сислога и dbus перейдет в пятый ранлевел, где запустится dm (если есть), а все остальное будет уже потом. Нафига это нужно, если все колом стоит пока не прогрузится?

То есть, ты утверждаешь, что последовательный systemd будет так же быстр?

Мне кажется что его можно сделать таким.
Из механизмов - паралельная загрузка и приоритеризация; как я понял только это и делает systemd с точки зрения ускорения загрузки. Еще один аргумент «bash скрипты медленны по сравнению с скомпилированным кодом» не принимаю, точнее мне кажется что это не критично в данном случае. Ну, и это кроме всякого, «выбросить ненужное», dhcp->статика, preload и т. п.

Без него это тоже делается.

Как? Есть success story?

Нафига это нужно, если все колом стоит пока не прогрузится?

Как раз после ввода логина и пароля (~~ 5 секунд в среднем, это с учетом того, что вводишь на сразу, а через 2-3 секунды.) все успевает прогрузится.

OMG. Не забудь его с libastral слинковать.

Да как-то из коробки оно само, руками ничего не пилил. Домашний debian sid с кедами. От груба до kdm 8 секунд. SysV init.

Системд быстр, потому что написан нашим пророком Леннартом. А обычные системы инициализации написаны школьниками и пенсионерами на коленках. Вот именно так дело и обстоит. Именно так, да.

У systemd есть секретное комбо: SSD.

Аминь.

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

Это бесподобно :D

Что такого там в этом systemd, что оно позволяет делать загрузку за несколько секунд?

Оно не в systemd, оно в SSD.

А разницы между systemd и обычными init-скриптами между федорами 13...17 я лично не заметил

А разницы между systemd и обычными init-скриптами между федорами 13...17 я лично не заметил

Вот-вот, какое-то поголовное плацебо у фанбоев systemd.

Что такого там в этом systemd, что оно позволяет делать загрузку за несколько секунд? Как это работает?

Там основная киллер-фича не просто в параллельном запуске демонов (например, как в OpenRC, учитывая зависимости), а в том, что демоны запускаются одновременно, не учитывая зависимости от других демонов. Смысл в том, что демон, зависящий от другого демона, как-то с ним общается: через сокет или D-Bus. Но демон может начать писать в сокет не сразу, поэтому можно запустить оба демона одновременно, чтобы они инициализировались вместе, а когда первый демон начнёт писать в сокет, предоставляемый вторым демоном, он будет ждать, пока сокет реально создастся вторым демоном. Т.е. инициализация обоих демонов до первого использования сокета проходит одновременно.

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

Ну и ещё в systemd есть бонус в виде запуска демонов, когда они нужны. Например, cups можно запускать при подключении принтера и останавливать при отключении.

Потому, что сишечка, а не баше-шкрипты; ну и нормальная многопоточность, да.

катимся, да

Почитать ман, взять systemd-analyze и посмотреть - неподъемная задача.

Наконец-то что-то интересное.

Смысл в том, что демон, зависящий от другого демона, как-то с ним общается: через сокет или D-Bus.

Каким образом это происходит? Например, squid зависит от dhcpd. Каким образом squid будет общаться с dhcpd?

В квотезы!

Лорчую :)

Потому, что сишечка, а не баше-шкрипты

Ок, +1% к скорости загрузки.

ну и нормальная многопоточность, да.

Чем отличается от той, что в openrc?

Почитать ман, взять systemd-analyze и посмотреть - неподъемная задача.

Читал. Пока ничего не нашел. Стоит ли читать дальше/больше?

Например, squid зависит от dhcpd.

Неправда, squid не зависит от dhcpcd. Его следует запускать, когда поднята сеть, поэтому он зависит от network.target, а что предоставляет network.target, неважно, будь то dhcpcd, dhclient, юнит, прописывающий статику или NetworkManager. Этот пример никак не относится к усовершенствованной параллелизации в systemd, но и тут проявляется его плюс: он может узнать, когда сеть реально поднята, и тогда запустить network.target, в то время как традиционные системы не определяют, когда NetworkManager поднимет сеть, а запускают squid просто после запуска NetworkManager, даже если сети ещё нет.

Примером одновременного запуска зависящих один от другого демонов может быть dbus-daemon и демон syslog. В традиционной системе dbus-daemon будет запущен позже, чем syslogd, потому что dbus-daemon может писать в системный лог сообщения. Но на самом деле syslogd просто предоставляет unix-сокет /dev/log, а dbus-daemon пишет в этот сокет, чтобы поместить в лог сообщение. Systemd может запустить оба демона одновременно. Если dbus-daemon начнёт писать в лог сообщения раньше, чем syslogd инициализируется, распарсит свой конфиг, откроет сокет и будет готов к работе, то данные закэшируются, а после заполнения кэша dbus-daemon заблокируется, пока не продуплится syslogd и считает из сокета. В данном случае сокет создаётся самим systemd, а syslogd должен уметь получить уже существующий сокет от systemd.

Тут написано об этом подробно: http://0pointer.de/blog/projects/socket-activation.html

не знаю, у меня systemd грузится примерно также, как initscripts

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

Socket activation occurs when a service allows systemd to listen for connections to a specific socket and, when systemd receives a connection on that socket, it starts the service. To do this, the upstream source needs to have some minor coding work to let systemd listen for connections on the socket and there needs to be a .socket file in %{_lib}/systemd/system/ that tells systemd to listen to that socket and what to start when a connection is received. This is similar in function to inetd and some, but not all, services coded to work with inetd will work with socket activation. Simila to inetd, using socket activation for on-demand loading will impose a startup time penalty so we currently do not use this feature in Fedora. 

Currently we do not have guidance on how to write socket files as this is something that needs upstream code and they can add a proper .socket file at the same time.

а). сокет-активейшн должен поддерживаться апстримом

б). это даёт замедление.

Это другое применение, когда демон запускается по требованию, например, запуск sshd с помощью sshd.socket, когда приходит соединение. В этом случае просто делается systemctl enable sshd.socket, чтобы systemd слушал 22 порт и запускал sshd для каждого соединения.

В случае, о котором рассказывал я, не происходит активация syslogd по сокету, когда dbus-daemon начнёт писать в /dev/log. В этом случае syslogd запускается, потому что он находится где-нибудь в sysinit.target, а не потому что в сокет пришли данные. А механизм активации по сокету используется для того, чтобы dbus-daemon мог писать в сокет, пока syslogd ещё не до конца запустился, а не для начала запуска syslogd.

То, что демоны запускаются одновременно в количестве виртуальных ядер процессора, а не в соответствии с деревом зависимостей, даёт ускорение, потому что ни одно ядро процессора не простаивает. А о том, что активация по сокету должна поддерживаться демоном, я говорил:

syslogd должен уметь получить уже существующий сокет от systemd.

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

However, socket activation can also be used to allow parallel startup of services. If a service supports systemd socket activation as described above and we additionally start it explicitly on boot, then systemd will start it but allow things that depend on it to startup at the same time. If the dependent service makes a request to the socket activatable service before it has come up, then systemd will cause the request to wait until the socket activatable service has come up and can process the request. To achieve this effect, the service must be socket activatable as described above, the .service file for the service needs to have a Wants= line for the .socket, and the service must autostart. Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart.

Описано вкусно, но все равно как-то не стыкуется.

Ок, с однонаправленными потоками понятно: отослал - забыл. Но ведь как правило сокеты поднимаются не просто так - кроме того как отослать, нужно еще и что-то получить. Ок, буфферизация: как появится реальный сокет, произойдет обмен; но тогда програма все равно будет ждать ответа. А значит результат будет очень близким к тому, что делает preload (основные задержки ведь - на чтении с диска).

А потом возникает много рисков: увеличивается время ответа - как там с таймаутами? А если результирующий сокет не поднимется, что тогда? Ведь програме systemd уже сообщил что информация отправлена, а тут оп, облом, реальный сокет не поднялся; что делать?

Получается что эта фишка применима только к syslog (и то, как я понял, временные метки будут каверкаться), да как повторении идеи initd; но в последнем случае уже говорилось почему отказались.

В общем с фичей понятно, с профитом (а конкретнй - с бенефитом минус затраты) - не совсем.

ну почитать документ от поттеринга уже нельзя чтоли?

делается, но сложнее.

Что может быть непонятного в запуске по требованию?