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

не просто одновременно а как только так сразу, фишку с сокетами сервиса до старта сервиса так просто под одновременно не запихнёшь.

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

Причем тут запуск по требованию? Мы обсуждаем создание фейковых сокетов до открытия реальных и кеширование вывода эти сокеты.

лол, в квотез

и она не рекомендована таки ибо за зависимостями в рц скриптах никто особо не следит.

сокетов не было и более быстрых версий простых шелл функций.

я уже не помню ( но в анонсе системд всё было просто и понятно написано, но этот путь не для Ъ

Запуск по требованию к причине появления этих сокетов. О какого рода кешировании идет речь?

Следит, я лично смотрел скрипты. Gentoo.

Да, и она не работает

Анонс был похож на рекламу Apple: все так клево, и все общими словами; только, если всмотерться в суть - все это есть и так. Ну, кроме бинарных логов, которые на десктопе только дополнительный гемор принесут.

Пруф есть?
УМВР.

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

https://bugs.gentoo.org/show_bug.cgi?id=391945

Собственно, он виснет. У меня оно почти всегда вешало шатдаун. Иногда вешало и бут, обычно было связано с депами сетевых интерфейсов.

есть вполне тестыкоторые показали реальную разницу. но это пару секунд в худшем случае.

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

Да, программа подождёт, пока поднимется настоящий демон и выдаст ей ответ.

А значит результат будет очень близким к тому, что делает preload (основные задержки ведь - на чтении с диска).

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

А потом возникает много рисков: увеличивается время ответа - как там с таймаутами?

Раньше сработает внутренний таймаут самого systemd, чем таймаут сокета (кстати, у unix-сокетов есть таймауты?).

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

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

Получается что эта фишка применима только к syslog

Не только. Это применимо ко всем демонам, управляемым через сокет, которые поддерживают systemd. А ещё же есть D-Bus — там тоже есть аналогичная фича, связанная с активацией по шине, и здесь даже не нужна модификация демона, поэтому такая фича доступна ещё и для демонов, предоставляющих интерфейсы на D-Bus.

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

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

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

А потом возникает много рисков: увеличивается время ответа - как там с таймаутами? А если результирующий сокет не поднимется, что тогда? \\ это случай когда сислог не запустился что будет в стандартном ините в таком случае?

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

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

С systemd в VirtualBox в Gentoo Hardened у меня получалось, ЕМНИП, 1.4 секунды. Из ядра было выпилено почти всё, оставил сеть, выпилил консоль, клавиатуру, мышь и прочие ненужные вещи, при этом был включён PaX и GrSecurity (без них было бы быстрее). Запускались только sshd, systemd-udevd и systemd-journald, поднималась сеть по dhcp, проверялась ФС ext4 на жёстком диске. И ещё в VirtualBox стояло ограничение на загрузку процессора не больше 75%, что замедлило загрузку.

На настоящем железе очень долго грузится ядро — 4 секунды. Всякие дополнительные опции снизили только до 2.7, при этом потом время опять выросло. Жаль, что это время не может уменьшить systemd.

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

Полагаю systemd должна делать что-то сходное.

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

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

УТПВР

Полагаю systemd должна делать что-то сходное.

Если смазать экран соплями 16-тилетней девственницы, время загрузки сократится вдвое.

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

пока нет но вроде в планах.

но там простое кэширование и сбор статистики для приоритезации.

Я слышал вроде она стала deprecated. Да и openrc грузится гораздо медленнее systemd

и 6 секунд это от нажатия кнопки.

А вот это круто. Жаль, что я так и не решил свою проблему с ядром.

Попробую по приколу. =)

Что значит зачем? Чтобы всякие вторичные сервисы (по типу cups, ssh там и т.п, которые нужны, но не сразу) грузились одновременно с сеансом kde (в идеале бы заставить их грузиться после него, но не получится).

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

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

Спасибо, доходчиво объяснили. :) Примерно так и подозревал.

Попробую по приколу. =)

Только не забудь затолкать в boot также зависимости kdm.

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

Я сейчас могу ошибаться, но afaik отложенный запуск это другое. Я ещё не разбирался как работает systemd, но менял в Альте инит на systemd и заметил фичу - когда я запустил nm-applet вручную, systemd запустил network manager, а не во время загрузки.

когда я запустил nm-applet вручную, systemd запустил network manager, а не во время загрузки

Т.е. до этого сети нет? Круто, чё.

Т.е. до этого сети нет? Круто, чё.

NM даже запускаясь при загрузке начинает подключаться только тогда, когда какой-то клиент запустился. Там ещё есть какие-то «системные подключения», может они подключаются и без клиента, не пробовал, но... скажи - зачем на десктопе сеть до логина пользователя?
Ну кроме частных случаев типа torrent-клиента, я как-то привык что у меня графический торрент клиент и он запускается вместе с графической средой. А всякая ерунда типа сетевых ФС, ntpdate и прочее, может запуститься и после того, как пользователь залогинился и nm подключился.
А теперь самое главное - наверняка в systemd при желании легко и просто включить запуск нужной службы при загрузке, так что всё ок же.

заметил фичу - когда я запустил nm-applet вручную, systemd запустил network manager, а не во время загрузки.

NetworkManager активировался через D-Bus, когда nm-applet захотел обратиться к нему. Можно выполнить systemctl enable NetworkManager.service, тогда он будет запускаться при загрузке, а не при попытке доступа к нему.

Системные подключения подключаются при старте NM. Так что если пихнуть NM в бут депы, то он, соответственно, поднимет сеть до логина

грустная часть тут в том что вайфай и подобные при этом иногда не стартовали. причём вероятно на уровне уефи(он там всётаки не полноценный был)

Чего именно тебе не хватает? Всё, что только может понадобиться, в линуксе давно есть

Как? Есть success story?

cat /etc/init.d/rc

# Specify method used to enable concurrent init.d scripts.
# Valid options are 'none' and 'makefile'. 
[SKIP]
# The default since the same date is 'makefile', as the init.d scripts 
# in Debian now include dependency information and are ordered using this
# information.  See insserv for information on dependency based boot sequencing.
CONCURRENCY=makefile

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

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

Сначала убеждаешь меня во всех темах, что Ubuntu - Linux, а потом заявляешь, что в Linux'е программ нужных нет. Попробуй «Полную установку» с DVD-версии RPM-based дистрибутива, а потом скажи, чего не хватает (кроме проприетарного, потому что его нет на диске дистрибутива).

Вот как раз проприетарного и не хватает, да. Да и некоторое свободное работает иногда лучше в винде.

Ну и да, понимаешь разницу между «не установлена» и «не существует»?

Пришел поручик и все опошлил :)

Ты и тут убунту собираешься обсуждать? Угомонись ;)

той, что в openrc?

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

Вот марк — космонавт, а ты — сосёшь хуй, это показывает, что убунтоводы — успешные люди, а ты хуесос.

https://bugs.gentoo.org/show_bug.cgi?id=391945
Собственно, он виснет.

Эту опцию уже наверно как полгода, если не больше исключили из openrc. Без нее с ssd и uefi загрузка идет 4 сек. Оно реально надо кому-то быстрее, чтобы ковыряться и тратить время?

(Не)возможность параллельной загрузки - индикатор кривости системы. На десктопе у меня линакс грузится с опенрц около полутора минут. Без SSD и UEFI. Впрочем, скорость дело второстепенное.

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

У тебя однозадачный линукс? Где брал?

ТС, тебя покусал журналист?

Я сейчас подумал... что правильнее было бы не пихать тогда уж kdm в boot, а создать новый runlevel, например, 3-й.. туда пихнуть kdm со всеми зависимостями. А, например, в 4-й уровень запихать всё остальное..

Попробовать что ли и правда ради прикола. :)

А в boot пихать вроде надо только самые важные сервисы...