The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В BusyBox прекращена поддержка systemd, opennews (??), 30-Окт-15, (0) [смотреть все] –2

Сообщения [Сортировка по времени | RSS]


225. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 01-Ноя-15, 15:40 
> Вы можете точно рассказать, какие действия и в какой последовательности происходят при
> загрузке вышей системы? Как если бы вы загрузились с init=/bin/sh и
> набрали все вручную.

Конечно, могу. Достаточно в /etc/systemd/systemd.conf поставить LogLevel=debug, а также убрать опцию quiet из командной строки ядра, и вы прекрасно всё увидите в журнале, какие сервисы и в какой последовательности стартанули.

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

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

Ответить | Правка | Наверх | Cообщить модератору

226. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 01-Ноя-15, 15:42 
Опечатался. Правильно: /etc/systemd/system.conf
Ответить | Правка | Наверх | Cообщить модератору

235. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от Mihail Zenkov (ok), 01-Ноя-15, 17:02 
> Конечно, могу. Достаточно в /etc/systemd/systemd.conf поставить LogLevel=debug, а также
> убрать опцию quiet из командной строки ядра, и вы прекрасно всё
> увидите в журнале, какие сервисы и в какой последовательности стартанули.

Очень интересно было бы на это посмотреть, если не сложно - выложите лог.

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

Сомневаюсь, что с systemd система будет грузится быстрее, чем с хорошо продуманным инитом под конкретную систему, который по факту может уложится в 20-30 команд.
У меня есть стары ноутбук (1.66Mhzx2) который грузится за 7 секунд, выключается за 1-2 секунды.

> А также существенно упростился анализ зависимостей сервисов.

Сколько, каких (и зачем) сервисов у вас запущенно, что для них нужен анализ зависимостей?

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

250. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от IZh. (?), 01-Ноя-15, 18:58 
Вот, например, журнал загрузки виртуалки с openSUSE 13.2: http://pastebin.com/shju9AeT
Здесь, правда, есть такой момент, что systemd стартует два раза: один раз в initrd, сгенерированном dracut'ом, а второй, непосредственно, с корневой файловой системы.

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

Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов, что трудно организовать, используя классический SysV init.

Анализ зависимостей сервисов требуется для ускорения загрузки, когда пытаетесь понять, действительно ли сервис A должен стартовать после сервиса B, и можно ли сделать так, чтобы они стартовали параллельно. Правда, в случае с мобильными телефонами может оказаться не всё так просто, и если стартовать все сервисы одновременно, загрузка системы может стать даже медленнее, чем если разбить все сервисы на несколько групп (с разумным пареллелизмом), а группы стартовать последовательно.

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

К тому же удобно управлять сервисами: включать/выключать/запрещать. И нет проблем с зависимостями, типа, что mysql остановили, а apache с сайтом, который может к нему обращаться, ещё работает -- забыли остановить в первую очередь.

В случае с вашим ноутбуком ответ можно вполне точно прикинуть, можно ли ускорить загрузку. Есть инструменты (типа того же bootchart'а), которые записывают загрузку CPU и дисковой подсистемы во время старта системы. И если у вас всё загружено под завязку, то, да, улучшить не получится. А если что-то простаивает, то есть шанс, что можно что-то переупорядочить, и, тем самым, ускорить загрузку.

Ответить | Правка | Наверх | Cообщить модератору

252. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 01-Ноя-15, 19:40 
> Вот, например, журнал загрузки виртуалки с openSUSE 13.2: http://pastebin.com/shju9AeT

Спасибо.

> Здесь, правда, есть такой момент, что systemd стартует два раза: один раз
> в initrd, сгенерированном dracut'ом, а второй, непосредственно, с корневой файловой системы.

Это не главное. Вы уверены, что из этого лога вы понимаете как стартует система? Я например не увидел в нем многих основополагающих вещей. Например в какой момент монтируется /sys /proc /tmp, в какой последовательности и с какими параметрами?

> Вся сложность понимания работы systemd состоит в том, что сервисы стартуют параллельно
> согласно графу зависимостей. В тоже время, для сервиса легко понять, от
> кого он зависит, и кто зависит от него. При этом есть
> инструменты, показывающие критический путь при загрузке -- узкое место, разобравшись с
> которым можно ускорить загрузку системы (systemd-analyze, bootchart).
> Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов, что
> трудно организовать, используя классический SysV init.

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

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

Телефон (android) - это показатель как не нужно делать. Количество сервисов там раздуто выше всякой меры.

> К тому же удобно управлять сервисами: включать/выключать/запрещать. И нет проблем с зависимостями,
> типа, что mysql остановили, а apache с сайтом, который может к
> нему обращаться, ещё работает -- забыли остановить в первую очередь.

Согласен. Но подобное нужно далеко не везде.

> В случае с вашим ноутбуком ответ можно вполне точно прикинуть, можно ли
> ускорить загрузку. Есть инструменты (типа того же bootchart'а), которые записывают загрузку
> CPU и дисковой подсистемы во время старта системы. И если у
> вас всё загружено под завязку, то, да, улучшить не получится. А
> если что-то простаивает, то есть шанс, что можно что-то переупорядочить, и,
> тем самым, ускорить загрузку.

Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/ udev/etc по определению не может быть быстрее 20-30 команд шела.

Ответить | Правка | Наверх | Cообщить модератору

253. "В BusyBox прекращена поддержка systemd"  –1 +/–
Сообщение от IZh. (?), 01-Ноя-15, 19:55 
> Это не главное. Вы уверены, что из этого лога вы понимаете как
> стартует система? Я например не увидел в нем многих основополагающих вещей.
> Например в какой момент монтируется /sys /proc /tmp, в какой последовательности
> и с какими параметрами?

Данные файловые системы монтирует сам systemd, так как уже сложно представить себе систему, где данные файловые системы не монтируются или монтируются не туда (или с другими параметрами).

> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать. Действительно ли вам
> нужны все эти сервисы, что бы потом строить зависимости и думать
> как их параллельно запустить? Озвучите ваши задачи и необходимые для них
> сервисы и на чем основан их выбор.
> Телефон (android) - это показатель как не нужно делать. Количество сервисов там
> раздуто выше всякой меры.

А я и не об Андроиде говорил. Есть ещё Tizen и Sailfish. Количество разных сервисов/демонов достигает нескольких десятков, и иногда переваливает за сотню. В телефоне много подсистем, нуждаюзихся в своих сервисах -- сенсоры, модем, GPS, аудио, WiFi...

> Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/
> udev/etc по определению не может быть быстрее 20-30 команд шела.

Как раз systemd и позволяет не запускать сотни команд. Init-скрипты плохи тем, что для каждого скрипта инстанциируется свой процесс bash'а (ну, или какой шелл в системе стоит). А это тоже занимает времени. В случае же с systemd есть возможность, вообще, не запускать shell-процессы, ограничившись короткими ini-файлами, и запускать, непосредственно, процессы сервисов.

Ответить | Правка | Наверх | Cообщить модератору

254. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 01-Ноя-15, 19:58 
Судя по тому, что -1 стоит уже у каждого моего сообщения, какому-то хейтеру очень сильно не понравилось, что я пишу, и он решил из вредности заминусовать все мои сообщения. Детский сад, честное слово. ;-)
Ответить | Правка | Наверх | Cообщить модератору

256. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 01-Ноя-15, 21:12 
>> Это не главное. Вы уверены, что из этого лога вы понимаете как
>> стартует система? Я например не увидел в нем многих основополагающих вещей.
>> Например в какой момент монтируется /sys /proc /tmp, в какой последовательности
>> и с какими параметрами?
> Данные файловые системы монтирует сам systemd, так как уже сложно представить себе
> систему, где данные файловые системы не монтируются или монтируются не туда
> (или с другими параметрами).

В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке. Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.

>> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать. Действительно ли вам
>> нужны все эти сервисы, что бы потом строить зависимости и думать
>> как их параллельно запустить? Озвучите ваши задачи и необходимые для них
>> сервисы и на чем основан их выбор.
>> Телефон (android) - это показатель как не нужно делать. Количество сервисов там
>> раздуто выше всякой меры.
> А я и не об Андроиде говорил. Есть ещё Tizen и Sailfish.
> Количество разных сервисов/демонов достигает нескольких десятков, и иногда переваливает
> за сотню. В телефоне много подсистем, нуждаюзихся в своих сервисах --
> сенсоры, модем, GPS, аудио, WiFi...

Вы считаете этот подход правильным? Почему под gnu/linux можно обойтись минимумом демонов и при этом будут и сенсоры и куча другой периферии?

>> Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/
>> udev/etc по определению не может быть быстрее 20-30 команд шела.
> Как раз systemd и позволяет не запускать сотни команд. Init-скрипты плохи тем,
> что для каждого скрипта инстанциируется свой процесс bash'а (ну, или какой
> шелл в системе стоит). А это тоже занимает времени.

Сколько занимает, учитывая, что в системе инициализации обычно используется ash/dash? Да и ни кто не заставляет запускать скрипты десятками. У меня например четыре скрипта.

> В случае
> же с systemd есть возможность, вообще, не запускать shell-процессы, ограничившись короткими
> ini-файлами, и запускать, непосредственно, процессы сервисов.

Вы просто гляньте выложенный вами лог и скажите сколько процессов будет порождено пока система загрузится. Даже проще - напишите ps сразу по завершению загрузки и назовите pid последнего процесса.

Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

257. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 01-Ноя-15, 21:49 
> В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
> У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке.
> Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.

А как связана загрузка модуля с монтированием /proc, /sys и /tmp. Данные монтирования -- это всего-лишь три системных вызова, и происходят мгновенно. А далее, можно и ваш модуль параллельно грузить.

> Вы считаете этот подход правильным? Почему под gnu/linux можно обойтись минимумом демонов и при этом будут и сенсоры и куча другой периферии?

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

При разработке мобильных решений применяются другие критерии, нежели при разработке десктопных дистрибутивов. На первое место вылезают потребление CPU, памяти и питания. К тому же, иногда бывают решения, навязанные производителем данного конкретного SoC'а -- вот, есть предоставленные сервисные демоны, которые делают то-то, а других нету.

А, вообще, тут нужно более конкретно обсуждать. Брать какую-то подсисистему на десктопе и в мобильнике, и сравнивать.

А что касается номера последнего PID'а, то это некорректное сравнение. Нужно, как минимум, брать две системы с одинаковым набором сервисов -- одну на SysV init'е (или на чём пожелаете), а вторую на systemd. Ну, или хотя бы два десктопных дистрибутива.

В openSUSE 1107 после загрузки. Замечу, что одних ядерных потоков сейчас запущено 97. Так что это мало о чём говорит.

В случае с systemd процессов будет запущено однозначно меньше, чем в случае с init'ом, так как не надо запускать bash на каждый скрипт, и не надо запускать всякие ls, grep, sed, find, wc, awk и прочие утилиты, а можно просто задавать опции в unit-файле.

Ответить | Правка | Наверх | Cообщить модератору

258. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 01-Ноя-15, 23:12 
>> В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
>> У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке.
>> Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.
> А как связана загрузка модуля с монтированием /proc, /sys и /tmp. Данные
> монтирования -- это всего-лишь три системных вызова, и происходят мгновенно. А
> далее, можно и ваш модуль параллельно грузить.

Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет команд до того как будет загружен этот модуль?

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

Речь о другом: gnu/linux позволяет работать с датчиками и прочим железом без демонов. Есть конечно исключения типа wpa_suplicant, но обычно софт может обратится к устройству или sysfs напрямую.

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

К сожалению - сейчас нет. Там сплошной блоатваре, сжирающий память и cpu, а заодно и батарейку. Гляньте на rockbox - может работать на 1mb (для всех функций нужно 4mb) ram и 30-40MHz древнего arm. Потребление питания при програмном декодировании музыки 12-13ma.
Емкость аккумулятора современных телефонов доходит до 3000-4000mAh. То есть телефон (с отключенным модулем связи) под управлением rockbox смог бы играть музыку в течении 250-300 часов!

> А что касается номера последнего PID'а, то это некорректное сравнение. Нужно, как
> минимум, брать две системы с одинаковым набором сервисов -- одну на
> SysV init'е (или на чём пожелаете), а вторую на systemd. Ну,
> или хотя бы два десктопных дистрибутива.

Моя позиция иная сперва нужно выкинуть ненужное, а затем уж смотреть нужна ли столь сложная система инициализации.

Упомянутый мной ноутбук и десктоп с такой же системой используются для программирования (включая avr и arm), работы с 2d/3d графикой и работы со звуком. При этом gnu utils заменены на busybox, udev заменен mdev. d-bus/pa и прочие подобные вещи не использую.

> В случае с systemd процессов будет запущено однозначно меньше, чем в случае
> с init'ом, так как не надо запускать bash на каждый скрипт,
> и не надо запускать всякие ls, grep, sed, find, wc, awk

Допустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg) за простых 20-30 команд?

Ответить | Правка | Наверх | Cообщить модератору

259. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от IZh. (?), 01-Ноя-15, 23:38 
> Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет
> команд до того как будет загружен этот модуль?

Как вариант, если, уж, нужно Очень рано стартовать, напишут unit-файл с минимальными зависимостями, что позволит systemd запустить его первым или одним из первых. И всего-лишь с одной командой Exec=/sbin/modprobe ... Это, конечно, отчасти, хак, но если очень надо, то сделать можно.

> Речь о другом: gnu/linux позволяет работать с датчиками и прочим железом без
> демонов. Есть конечно исключения типа wpa_suplicant, но обычно софт может обратится
> к устройству или sysfs напрямую.

Ну, вот, с этим "обычно" и нужно разбираться более детально. С

> К сожалению - сейчас нет. Там сплошной блоатваре, сжирающий память и cpu,
> а заодно и батарейку. Гляньте на rockbox - может работать на
> 1mb (для всех функций нужно 4mb) ram и 30-40MHz древнего arm.
> Потребление питания при програмном декодировании музыки 12-13ma.
> Емкость аккумулятора современных телефонов доходит до 3000-4000mAh. То есть телефон (с
> отключенным модулем связи) под управлением rockbox смог бы играть музыку в
> течении 250-300 часов!

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

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

Если же вы про кучу ненужного предустановленного софта, то с этим согласен. Но это мало имеет отношения к systemd -- что поставили, то и запускает.

> Допустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg)
> за простых 20-30 команд?

В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом. Если для загрузки вашей системы требуется всего-лишь 20-30 команд, то, несомненно, их можно и в небольшое количество unit-файлов перенести.

Ответить | Правка | Наверх | Cообщить модератору

260. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 00:14 
> Вообще, первое место по потреблению энергии в сотовых сейчас занимает экран. При
> выключенном экране сотовый живёт в разы дольше. А ещё энергию жрёт
> GSM-модем. Поэтому сравнивать телефон с MP3-плеером не совсем корректно.

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

> Насчёт блоатвари, вопрос спорный. Попробуйте предложить другую архитектуру мобильной
> операционной системы: и чтобы у приложений был удобный доступ к сенсорам
> и т.п. (чтобы каждому приложению не надо было линковаться с низкоуровневыми
> библиотеками, а можно было использовать высокоуровневый API), и чтобы, при этом
> с безопасностью было всё в порядке, чтобы не позволять всем приложениям
> обращаться ко всему. Вот тут-то и повылезают демоны, являющиеся прослойкой между
> железом и непривилегированными приложениями.

gnu/linux и отказ от сомнительных маркетов/приложений?

> Если же вы про кучу ненужного предустановленного софта, то с этим согласен.
> Но это мало имеет отношения к systemd -- что поставили, то
> и запускает.

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

>> Допустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg)
>> за простых 20-30 команд?
> В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом.

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

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

В чем тогда смысл? Усложнить систему введя новую прослойку? Да и команд понадобится существенно больше, так как притянутся cgroups/udev/dbus.

Ответить | Правка | Наверх | Cообщить модератору

263. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от IZh. (?), 02-Ноя-15, 00:27 
>> В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом.
> Естественно. Но его действия можно представить аналогичным эквивалентом обычных команд.
> И их там будет существенно больше.

Считать, на мой взгляд, стоит не команды, а системные вызовы. Сколько системных вызовов происходит, пока запускается bash, чтобы исполнить Одну команду? В случае с systemd, это будет всего-лишь парочка системных вызовов.

>> Если для
>> загрузки вашей системы требуется всего-лишь 20-30 команд, то, несомненно, их можно
>> и в небольшое количество unit-файлов перенести.
> В чем тогда смысл? Усложнить систему введя новую прослойку? Да и команд
> понадобится существенно больше, так как притянутся cgroups/udev/dbus.

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

Ответить | Правка | Наверх | Cообщить модератору

265. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 00:51 
> Считать, на мой взгляд, стоит не команды, а системные вызовы. Сколько системных
> вызовов происходит, пока запускается bash, чтобы исполнить Одну команду? В случае
> с systemd, это будет всего-лишь парочка системных вызовов.

OK. Но не bash, а dash/ash. И в одном случае мы имеем интерпретатор в виде шела, в другом в виде systemd. Мы можем из одного шела запустить все нужные команды.

Сделайте strace для unit'a, а я сделаю для шела и можем посчитать системные вызовы.

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

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

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

Я могу не запускать udev совсем или заменить его mdev или чем еще?

Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

267. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 02-Ноя-15, 01:00 
> OK. Но не bash, а dash/ash. И в одном случае мы имеем
> интерпретатор в виде шела, в другом в виде systemd. Мы можем
> из одного шела запустить все нужные команды.
> Сделайте strace для unit'a, а я сделаю для шела и можем посчитать
> системные вызовы.

Не совсем так. systemd при старте сразу считывает все unit-файлы, и строит у себя в голове граф зависимостей. Далее, когда требуется запустить какой-то процесс, ему не нужно больше никаких скриптов исполнять. Он знает, что sshd запускается с помощью такого-то бинарника. Все системные вызовы, которые тут нужны -- всего лишь, чтобы форкнуться, настроить нужные права (при необходимости), и сделать exec на запускаемый бинарник. И никакой shell-магии.

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

Когда это реально не нужно, будет проделан минимум работы. Если вы не используете ограничения по памяти или CPU, то как я понимаю, работа с cgroup'пами будет минимальна -- только для контроля за тем, какие процессы какому сервису принадлежат (помещаем первый процесс сервиса в группу, потомки будут там же).

> Я могу не запускать udev совсем или заменить его mdev или чем
> еще?

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

Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

268. "В BusyBox прекращена поддержка systemd"  –1 +/–
Сообщение от IZh. (?), 02-Ноя-15, 01:08 
Вы же не сможете спорить, что программа на компилируемом языке всегда быстрее, чем на интерпретируемом, и что запуск процессов влечёт за собой накладные расходы, и при прочих равных условиях, чем меньше процессов, тем лучше?

systemd выигрывает за счёт двух вещей:
1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в виде параметров, а не в виде результатов работы внешних команд)
2) Параллельность

Но, как я уже говорил, настроить криво можно что угодно.
Я не верю, что при пряморукой настройке systemd может быть медленнее, чем куча shell-скриптов.

Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

271. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 01:23 
> Вы же не сможете спорить, что программа на компилируемом языке всегда быстрее,
> чем на интерпретируемом, и что запуск процессов влечёт за собой накладные
> расходы, и при прочих равных условиях, чем меньше процессов, тем лучше?

Да, но:
1. systemd тоже разбирает конфиги.
2. в 90% случаев вся интерпретация в шеле сводится к запуску конкретного бинарника


> systemd выигрывает за счёт двух вещей:
> 1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в
> виде параметров, а не в виде результатов работы внешних команд)

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

> 2) Параллельность

У меня это решается так:
nice -n 19 /etc/init.d/background &

Ответить | Правка | К родителю #268 | Наверх | Cообщить модератору

273. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 02-Ноя-15, 01:43 
> Да, но:
> 1. systemd тоже разбирает конфиги.
> 2. в 90% случаев вся интерпретация в шеле сводится к запуску конкретного
> бинарника

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

>> systemd выигрывает за счёт двух вещей:
>> 1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в
>> виде параметров, а не в виде результатов работы внешних команд)
> Но по факту он должен производить те же манипуляции, что и shell
> команды. В теории он может иметь выигрыш за счет меньшего количества
> процессов, но у него есть и собственные накладные расходы в виде
> cgroups/dbus и Поттеринг знает еще чего.

systemd не нужно, например, по десять раз инициализировать разделяемые библиотеки, что происходит при запуске шелла. Напшите ldd /bin/ваш-любимый-шелл. Сколько разделяемых библиотек могут захотеть проинициализироваться при старте процесса?

>> 2) Параллельность
> У меня это решается так:
> nice -n 19 /etc/init.d/background &

Это выглядит более похоже на костыль, чем на решение. Как вы определяете зависимости между сервисами? Как избегаете race condition'ов? На глаз? В случае с systemd можно прописать зависимости декларативно.

У systemd есть ещё плюс -- активация сервиса через сокет (socket based activation). Например, вы можете настроить систему так, чтобы sshd не запускался до первого соединения (нечто похожее на inetd).

Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

288. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 15:19 
> systemd не надо интерпретировать команды. Соответственно, ему не надо в голове иметь
> интерпретатор / виртуальную машину. Формат unit-файла чётко специфицирован. В нём могут
> встречаться только определённые ключевые слова и только в определённом месте. В
> результате есть возможность при старте системы прочитать все значения параметров, сохранить
> их в структуру, и больше не заниматься парсингом и т.п.

В теории красиво. Перейдем к практике.
Интерпретация в ash сводится к трем функциям. Первая читает из файла слова. Вторая используя switch ищет подходящий вариант спецсимвола. Третья используя все тот же switch ищет ключевое слово. Если слово не является спецсимволом или ключевым словом, то оно считается внешней командой и происходит попытка запуска. Всего 219 строк кода.

Интерпретация systemd: поиск unit файлов по всем закоулкам с привлечением dbus. Где оно точно парсит я так и не нашел, ибо размазано там все так, как ... Нашел функцию устанавливающую свойства - там каждый раз тоже активно используется dbus, если верно понял рассылает уведомления о изменении состояния свойства. Запуск тоже нашел - там ряд проверок, а вдруг unit уже запущен, а вдруг ему что мешает или не хватает и т.д. В общем там исполняются десятки тысяч строк кода (не считая dbus) дабы запустить один unit.

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

Зато у него на каждый чих - обращение к dbus ;)

> Напшите ldd /bin/ваш-любимый-шелл. Сколько разделяемых
> библиотек могут захотеть проинициализироваться при старте процесса?

ldd ash
        linux-gate.so.1 (0xb77a1000)
        libc.so.6 => /lib/libc.so.6 (0xb760e000)
        /lib/ld-linux.so.2 (0xb77a2000)

>>> 2) Параллельность
>> У меня это решается так:
>> nice -n 19 /etc/init.d/background &
> Это выглядит более похоже на костыль, чем на решение. Как вы определяете
> зависимости между сервисами?

Смотрю порядок исполнения в файле.

> Как избегаете race condition'ов? На глаз? В случае
> с systemd можно прописать зависимости декларативно.

Я предпочитаю не доводить систему до такого состояния :)
Сейчас в системе реально есть только один случай - нужно запускать графические программы только после того как загрузится xorg-server. Использую waitforx (исходник - 16 строк на c). Как кстати systemd определяет что xorg-server уже запустился?

> У systemd есть ещё плюс -- активация сервиса через сокет (socket based
> activation). Например, вы можете настроить систему так, чтобы sshd не запускался
> до первого соединения (нечто похожее на inetd).

А чем плох initd?

Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

289. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Michael Shigorinemail (ok), 02-Ноя-15, 18:32 
> (нечто похожее на inetd).
> А чем плох inetd?

Слишком долго уже просто работает, очевидно.

Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

291. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Michael Shigorinemail (ok), 02-Ноя-15, 18:52 
> У меня это решается так:
> nice -n 19 /etc/init.d/background &

Есть ещё ionice -c3, порой полезно (нынче умолчательный приоритет ввода-вывода связан и с nice, помнится, но в idle отодвинуть куда заметней).

Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

295. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 19:31 
> Есть ещё ionice -c3, порой полезно (нынче умолчательный приоритет ввода-вывода связан и
> с nice, помнится, но в idle отодвинуть куда заметней).

Да есть такой, раньше использовал для rtorrent, дабы уменьшить проявления 12309. Потом железо сменил, от свопа отказался и больше не сталкивался. Примирительно к инит системе не пробовал, возможно стоит. Пробовал e4rat, но существенной разницы не намерил. В любом случае, на данный момент самым тормозным местом является bios.

Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

297. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от arisu (ok), 02-Ноя-15, 19:51 
кстати, вопрос оффтопиком, но по ядру. опосля перехода на 4.2 и наращивания памяти до 8Gb получился странный конфуз: отчего‐то дисковые кэши на запись работают нормально только пока вся память не забивается кэшем чтения. после чего йок.

попробую пояснить «на пальцах»: сбрасываем кэши:
echo 3 >/proc/sys/vm/drop_caches
запускаем софтину, которая делает активные write(), часто и разные.
ядро, как и полагается, оные записи кэширует, всё летает.
работаем пол‐дня (или как получается).
запускаем ту же самую софтину.
ТОРМОЗААААААААА.
снова делаем echo.
запускаем ту же самую софтину.
летает.

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

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

так вот, вопрос: как пояснить ядру, что при прочих равных кэшированию записи надо отдавать приоритет, а не кэшированию чтения? а то даже простой git rebase тормозит нещадно. ;-)

Ответить | Правка | К родителю #295 | Наверх | Cообщить модератору

298. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Michael Shigorinemail (ok), 02-Ноя-15, 20:02 
> кстати, вопрос оффтопиком, но по ядру

Писал бы сразу в "Linux 4.3", а то и в lkml с воспроизводилкой?

Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

299. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от arisu (ok), 02-Ноя-15, 20:12 
> Писал бы сразу в "Linux 4.3", а то и в lkml с
> воспроизводилкой?

у мене 4.2. и решение, я сильно подозреваю, в том, что я тупо забыл подкрутить какой‐то ядерный параметр. потому спрашиваю тут — вдруг меня сразу носом ткнут, была у кого‐то такая же проблема, например. не ткнут — будем дальше копать. с воспроизводилкой тоже сложно: как воспроизвести «активно работать на моей дисковой конфигурации пол‐дня/день»? к тому же я обычно в целевые места хожу с уже готовыми решениями.

Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

301. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 21:46 
> дёргать ядерные параметры кэширования пробовал (так‐то они у меня в умолчаниях стоят),
> ничего кардинально не меняется. вообще.

А что происходит с Dirty и Writeback в /proc/meminfo смотрел?
Сейчас попробовал на своей системе (4gb) копировать большой файл (3gb) - MemFree становится 116mb, Dirty + Writeback = около 100mb.
Сделал "echo 30 > /proc/sys/vm/dirty_background_ratio" (было 10). Ничего не изменилось.
Сделал "echo 60 > /proc/sys/vm/dirty_ratio" (было 20). Dirty + Writeback = около 300mb.
Непонятно почему при таких больших значениях используется так мало памяти. Так что никому не доверяй и все проверяй ;)

Если еще не читал, то может будет полезно:
http://www.westnet.com/~gsmith/content/linux-pdflush.htm

Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

302. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от arisu (ok), 02-Ноя-15, 21:54 
> А что происходит с Dirty и Writeback в /proc/meminfo смотрел?

неа. отчего‐то запамятовал.

> Сейчас попробовал на своей системе (4gb) копировать большой файл (3gb) - MemFree
> становится 116mb, Dirty + Writeback = около 100mb.

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

> Сделал "echo 30 > /proc/sys/vm/dirty_background_ratio" (было 10). Ничего не изменилось.
> Сделал "echo 60 > /proc/sys/vm/dirty_ratio" (было 20). Dirty + Writeback = около
> 300mb.
> Непонятно почему при таких больших значениях используется так мало памяти. Так что
> никому не доверяй и все проверяй ;)

ну, видать, или быстро протухает, или как‐то догадывается, что не надо сильно стараться. ;-)

> Если еще не читал, то может будет полезно:
> http://www.westnet.com/~gsmith/content/linux-pdflush.htm

читал, но всё равно спасибо. как я уже писал, беда в том, что невозможно быстро воспроизвести, поэтому процесс ооооочень медленный. поменял, пол‐дня работаешь, забыл уже, опять тормозит, вспомнил, проверил, поменял… короче, таким макаром оно может на годы затянуться. %-)

Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

304. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 22:25 
> ну, видать, или быстро протухает,

Для это есть отдельные параметры.

> или как‐то догадывается, что не надо сильно
> стараться. ;-)

Тогда бы результат при поднятии параметров в три раза вызывал бы меньший рост. ИМХО оно как-то очень хитро считает и уж точно не на прямую от объема памяти.

> читал, но всё равно спасибо. как я уже писал, беда в том,
> что невозможно быстро воспроизвести, поэтому процесс ооооочень медленный. поменял, пол‐дня
> работаешь, забыл уже, опять тормозит, вспомнил, проверил, поменял… короче, таким
> макаром оно может на годы затянуться. %-)

Я бы в такой ситуации поставил эти два параметра в 3-4 раза больше исходных и ждал. Если все равно будет тормозить - то ловить момент и смотреть /proc/meminfo.

P.S Ты перешел на 64 бита, и я тут последний на 32 битах остался ? ;)

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

306. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от arisu (ok), 02-Ноя-15, 22:41 
> Я бы в такой ситуации поставил эти два параметра в 3-4 раза
> больше исходных и ждал. Если все равно будет тормозить - то
> ловить момент и смотреть /proc/meminfo.

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

> P.S Ты перешел на 64 бита, и я тут последний на 32
> битах остался ? ;)

неа, я всё там же, x86. просто по причине кота‐электромонтёра пришлось поменять технику, и в новой технике торчит 8Gb. ну, не выкидывать же теперь. ;-) заодно и ядро обновил — и вот такая вот ерунда началась.

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

313. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от arisu (ok), 07-Ноя-15, 03:34 
если вдруг кому интересно: я фиг знает, но после нижеследующего шаманства, похоже, ядро пришло в себя:

vm.dirty_ratio=40
vm.swappiness=5

don't even ask me. нет, я действительно не понимаю, где связь. но дисковые тормоза на записи пропали.

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

314. "В BusyBox прекращена поддержка systemd"  –1 +/–
Сообщение от Mihail Zenkov (ok), 07-Ноя-15, 13:30 
> vm.swappiness=5

А от свопа отказаться совсем не пробовал? ИМХО от него больше вреда, чем пользы.

Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

315. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от arisu (ok), 07-Ноя-15, 14:15 
> А от свопа отказаться совсем не пробовал? ИМХО от него больше вреда,
> чем пользы.

туда гибернатор гадит. а раз уж оно всё равно есть — пусть и будет, чо.

Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

261. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 00:18 
>> Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет
>> команд до того как будет загружен этот модуль?
> Как вариант, если, уж, нужно Очень рано стартовать, напишут unit-файл с минимальными
> зависимостями, что позволит systemd запустить его первым или одним из первых.
> И всего-лишь с одной командой Exec=/sbin/modprobe ... Это, конечно, отчасти, хак,
> но если очень надо, то сделать можно.

Когда именно? Перед монтированием procfs/sysfs/tmpfs или после? Или вообще после монтирования всех разделов и прогона fsck? А может еще после dbus и udev?

Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

262. "В BusyBox прекращена поддержка systemd"  +1 +/–
Сообщение от IZh. (?), 02-Ноя-15, 00:23 
> Когда именно? Перед монтированием procfs/sysfs/tmpfs или после? Или вообще после монтирования
> всех разделов и прогона fsck? А может еще после dbus и
> udev?

sys/proc/tmp монтируются практически сразу после запуска systemd. Раньше только initrd.
Но уже после, при желании, можно и запустить что-нибудь.

Ответить | Правка | Наверх | Cообщить модератору

264. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 00:35 
> sys/proc/tmp монтируются практически сразу после запуска systemd. Раньше только initrd.
> Но уже после, при желании, можно и запустить что-нибудь.

А переведенный вами пример загрузки говорит об обратном:
https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...

Или я что-то не понял?

P.S. initrd на реальном среднем железе тоже 8 секунд грузится? Если так, то о какой скорости загрузки вообще можно говорить? Как я уже сказал, на старом ноуте к этому времени уже Xorg/dwm/st/mc/conky загрузятся.

Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

266. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 02-Ноя-15, 00:54 
> А переведенный вами пример загрузки говорит об обратном:
> https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...
> Или я что-то не понял?

Не говорит. На приведённом примере показан запуск сервисов. Монтирование /sys захардкожено в systemd. Приведённая картинка -- всего-лишь пример работы systemd-analyze -- инструмента, дуступного "из коробки" (в отличие от SysV init). Я не утверждал, что картинка соответствует оптимально настроенной системе. Криво настроить можно что угодно -- хоть systemd, хоть init.

Если хотите примеров быстрой загрузки, то, например, вот: https://www.youtube.com/watch?v=Xni2eIZdtrE

Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

269. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 01:11 
> Не говорит. На приведённом примере показан запуск сервисов. Монтирование /sys захардкожено
> в systemd.

А монтирование остальных fs и fsck не захардкожены?

> Приведённая картинка -- всего-лишь пример работы systemd-analyze -- инструмента,
> дуступного "из коробки" (в отличие от SysV init).

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

Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

270. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от IZh. (?), 02-Ноя-15, 01:21 
> А монтирование остальных fs и fsck не захардкожены?

Нет. Монтирование остальных файловых систем и fsck происходит согласно тому, что написано в unit-файлах.

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

Не хочу в час ночи, когда уже полусонный, курочить систему. Такое лучше на свежую голову.

В systemd всё чётко по зависимостям. Если корневая файловая система у вас уже примонтирована, то вы можете запускать любой бинарник. В конце концов, fsck же как-то запусается? Никто не мешает вам сделать unit-файл, который будет запускать вашу команду.

Ответить | Правка | К родителю #269 | Наверх | Cообщить модератору

272. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Mihail Zenkov (ok), 02-Ноя-15, 01:35 
> Не хочу в час ночи, когда уже полусонный, курочить систему. Такое лучше
> на свежую голову.

А в обычном ините - просто одну строку в самое начало файла вставить и ничего курочить не надо :)

Ответить | Правка | К родителю #270 | Наверх | Cообщить модератору

274. "В BusyBox прекращена поддержка systemd"  –1 +/–
Сообщение от IZh. (?), 02-Ноя-15, 01:45 
> А в обычном ините - просто одну строку в самое начало файла
> вставить и ничего курочить не надо :)

А здесь всего-лищь короткий unit-файл. :-) Просто, чтобы сгенерировать bootchart, придётся перегружаться.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

292. "В BusyBox прекращена поддержка systemd"  +/–
Сообщение от Michael Shigorinemail (ok), 02-Ноя-15, 18:59 
> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать.

Это же redhat.  Они и usrmove учинили вместо того, чтоб починить кривую линковку своего барахла из /sbin с библиотеками из /usr и оторвать руки как раз таки Леннарту, у которого pulseaudio хотело слазить в /usr/share за usb.ids непременно на ранней стадии своей инициализации.

Вместо разгребания авгиевых конюшен строят рядом ещё бОльшие...

Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

290. "В BusyBox прекращена поддержка systemd"  +2 +/–
Сообщение от Michael Shigorinemail (ok), 02-Ноя-15, 18:40 
> Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов,
> что трудно организовать, используя классический SysV init.

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

> Анализ зависимостей сервисов требуется для ускорения загрузки

Скажите, пожалуйста, а зачем нужны затыки на загрузке?  И особенно -- на выключении?

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

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

> К тому же удобно управлять сервисами: включать/выключать/запрещать.

Тридцать лет было удобно -- и наконец-то стало удобно.

Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

251. "В BusyBox прекращена поддержка systemd"  –1 +/–
Сообщение от IZh. (?), 01-Ноя-15, 19:12 
Вот, например, вывод от systemd-analyze: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...

А вот вывод от bootchart'а, который показывает, насколько загружен процессор в тот или иной момент: http://git.fenrus.org/tmp/bootchart-20120512-1036.svg

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру