Systemd'ова болезнь

[beroal]

Если то же самое можно делать в sysvinit, то я тем более не понимаю, что привело alv-а в недоумение. Имеем альтернативы: sysvinit и systemd. Можно перенести знания с одного случая на другой?

Почему вы считаете, что сеть должна запускаться для графического интерфейса? Существуют веб-броузеры для curses, существуют программы для X11, которым не нужна сеть.

[eddy]

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

Ну и на кой черт человеку, у которого все отлично работает с sysvinit, втыкать себе зонд свечи от геморроя и заниматься чушью?

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

А потому что обычно всякие httpd, proftpd, sshd и прочая запускаются до графики, т.к. являются более важными.

я тем более не понимаю, что привело alv-а в недоумение

Объясняю: был у вас рабочий автомобиль на карбюраторном двигателе, который отлично ездил. И тут вам говорят: а ну-ка, выкидывай свой карбюраторный движок и ставь дизель!

[diesel]

alv, основная идея systemd в том, что программы запускаются согласно их зависимостям, а не согласно порядку, который был задан системным администратором. Всё остальное следует из этого. Изучать нюансы systemd требует времени, но хотя бы эту идею вы могли усвоить?

основная идея systemd в том, что все сервисы запускаются *одновременно*, а не "согласно зависимостям" или "порядку, который был задан системным администратором".

[beroal]

основная идея systemd в том, что все сервисы запускаются *одновременно*, а не "согласно зависимостям" или "порядку, который был задан системным администратором".

Не знаю, что вы имеете в виду. Возможность задавать зависимости там есть.

[serzh-z]

основная идея systemd в том, что все сервисы запускаются *одновременно*, а не "согласно зависимостям" или "порядку, который был задан системным администратором".

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

[beroal]

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

А потому что обычно всякие httpd, proftpd, sshd и прочая запускаются до графики, т.к. являются более важными.

Не могу согласиться с этим аргументом. Важность — понятие субъективное. Порядок запуска следует определять по тому, может ли некоторая программа корректно работать без того или иного работающего демона.

[diesel]

основная идея systemd в том, что все сервисы запускаются *одновременно*, а не "согласно зависимостям" или "порядку, который был задан системным администратором".

Не знаю, что вы имеете в виду. Возможность задавать зависимости там есть.

основное отличие systemd от предыдущего "поколения" init-демонов, это как раз не "старт по зависимостям", а просто одновременный старт всех сервисов которые должны стартовать.

основная идея systemd в том, что все сервисы запускаются *одновременно*, а не "согласно зависимостям" или "порядку, который был задан системным администратором".

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

ну если говорить про старт сервисов - то это основная идея. дальше идут расширения этой идеи до перекрытия функциональности (x)inetd, cgroups etc.

[beroal]

Лично мне это доставляло бы неудобство - дважды жать на кнопку восстановления сеанса

Кстати, у меня Firefox начал время от времени предлагать восстановить сеанс задолго до установки systemd. Интернет у меня запускался до Firefox. Но мне лень было разбираться с этим глюком. Так что причина может быть не в сети; какая-то более сложная причинно-следственная связь.

[beroal]

основное отличие systemd от предыдущего "поколения" init-демонов, это как раз не "старт по зависимостям", а просто одновременный старт всех сервисов которые должны стартовать.

Под «сервисами, которые должны стартовать», вы имеете в виду те сервисы, которые требуются для default.target?

[Ali1]

Мне казалось, что основная идея systemd: унифицированный запуск и контроль всех системных служб(не только демонов).

[Bizdelnick]

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

Так в чём же основная? Откройте кто-нибудь, наконец, тайну, зачем нам на самом деле нужен этот systemd.

основное отличие systemd от предыдущего "поколения" init-демонов, это как раз не "старт по зависимостям", а просто одновременный старт всех сервисов которые должны стартовать.

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

[alv]

Имеем альтернативы: sysvinit и systemd.

Насколько я знаю, только в openSUSE. И пока. В 12.3 альтернативы уже не будет.

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

Не для, а до.
Потому что
а) это не я считаю, а общее мнение, что запуск - это приведение машины в работоспособное состояние;
б) если после загрузки DM продолжают грузиться какие-то службы - значит, время загрузки нужно измерять не между GRUB'ом и DM, а каки-то другим событием.
Это я и называют подтасовкой.

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

Насколько я понимаю основную идею (если она там есть) - это создание сокетов между процессами до запуска самих процессов.
Следствие - возможность одновременного запуска взаимозависимых процессов. Всё остальное - следствия этого следствия

выкидывай свой карбюраторный движок и ставь дизель!

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

причина может быть не в сети; какая-то более сложная причинно-следственная связь.

Возможно. Но при sysV это не проявлялось, при systemd - пожалуйста.
И ладно бы в FF, от которого можно всего ждать.
Но то же появилось и в konqueror'е с rekonq'ом, за которыми безобразий не водилось вообще

А зачем им стартовать одновременно?

Тайна сия велика есть...

[diesel]

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

Насколько я понимаю основную идею (если она там есть) - это создание сокетов между процессами до запуска самих процессов.
Следствие - возможность одновременного запуска взаимозависимых процессов. Всё остальное - следствия этого следствия

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

основное отличие systemd от предыдущего "поколения" init-демонов, это как раз не "старт по зависимостям", а просто одновременный старт всех сервисов которые должны стартовать.

Под «сервисами, которые должны стартовать», вы имеете в виду те сервисы, которые требуются для default.target?

под "сервисами которые должны стартовать" понимается например содержимое директории /etc/rc1.d в Debian'е, ну или вашего любимого ранлевела в вашем любимом дистрибутиве.

основное отличие systemd от предыдущего "поколения" init-демонов, это как раз не "старт по зависимостям", а просто одновременный старт всех сервисов которые должны стартовать.

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

шобы быстрее было

[Bizdelnick]

шобы быстрее было

А шо ж не быстрее?

[diesel]

шобы быстрее было

А шо ж не быстрее?

Чисто теоретически: OpenSuSE для обоих случаев которые тестились использует одни и те же стартовые скрипты, каким init'ом запускать шелл-скрыпт не особо то и важно Проверить сейчас не могу.

[alv]

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

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

Параллельный доступ к файлам тоже лучше последовательного

Кстати, к случаю с PATA и SATA это тоже относится?

каким init'ом запускать шелл-скрыпт не особо то и важно

так зачем огород городить?

[serzh-z]

Мне казалось, что основная идея systemd: унифицированный запуск и контроль всех системных служб(не только демонов).

Именно, про это очень много и с восторгом написано в блоге автора, а так же в брошюре "systemd for Administrators" (не помню какого автора).

Так в чём же основная? Откройте кто-нибудь, наконец, тайну, зачем нам на самом деле нужен этот systemd.

Я уже кидал выше ссылку. Но попробую подытожить (имхо, сложившееся после изучения мануалов, сравнений, блогов и постов сторонников systemd):

- сильное упрощение и стандартизация написания скриптов сервисов: любое приложение можно запустить сервисом в любом дистрибутиве без особых сложностей и без написания дистроориентированного (и поддерживающего контроль запуска зависимостей) скрипта запуска/остановки/перезапуска
- избавление от хака с демонизацией: детач управляющего терминала. Тот самый хак с вызовом daemon или порождением двух дочерних процессов
- удобство логирования вывода демона: демону не нужно писать в лог, он может всё выводить в stdout и systemd сумеет перехватить и сохранить весь вывод
- удобство управления подпроцессами демона: многие демоны создают несколько дочерних процессов (Apache), которыми сложно управлять. Если умер главный процесс демона, то: а) скрипт сервиса этого не видит; б) дочерние процессы продолжат бесконтрольно работать
- решение проблемы чрутирования демонов, cgroups
- отложенная активация сервисов

[beroal]

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

Не для, а до.
Потому что
а) это не я считаю, а общее мнение, что запуск - это приведение машины в работоспособное состояние;
б) если после загрузки DM продолжают грузиться какие-то службы - значит, время загрузки нужно измерять не между GRUB'ом и DM, а каки-то другим событием.
Это я и называют подтасовкой.

Работоспособное состояние — понятие относительное. Надо указывать, какие программы должны быть запущены для достижения работоспособного состояния. Если в тестах для systemd и sysvinit эти программы разные, то, конечно, подтасовка налицо. Я иногда начинаю работу просто в текстовой консоли, хотя DM должен быть наготове.

[beroal]

Параллельный доступ к файлам тоже лучше последовательного

Кстати, к случаю с PATA и SATA это тоже относится?

Это относится к механическому устройству жёсткого диска, а не к интерфейсу передачи данных.

[diesel]

каким init'ом запускать шелл-скрыпт не особо то и важно

так зачем огород городить?

ну собсно идея автора была убрать огороды из шелл-скриптов, для запуска всего на свете. если оставить скрипты, то от systemd не то чтобы толку есть - в общем-то он просто не отличается тогда от обычного init'а.

[yars]

Udev таки форкнули, так что RHEL, я думаю, будет использовать systemd, а остальные (кому не нравится systemd) - init+udev-ng.

[eddy]

Udev таки форкнули, так что RHEL, я думаю, будет использовать systemd, а остальные (кому не нравится systemd) - init+udev-ng.

О, может, в арчике появится-таки.
Насчет форка udev, кто-то мне на ЛОРе говорил, что у него - самосборный udev, не требующий костылей.

[alv]

Если в тестах для systemd и sysvinit эти программы разные, то, конечно, подтасовка налицо.

Дело не в разности программ. А в том, что в одном случае меряется "от забора и до обеда", во втором - "от меня до следующего столба".

serzh-z
Спасибо за очень внятное описание. У адептов systemd'а я такого не встречал

[alv]

идея автора была убрать огороды из шелл-скриптов, для запуска всего на свете. если оставить скрипты, то от systemd не то чтобы толку есть - в общем-то он просто не отличается тогда от обычного init'а.

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

стандартизация написания скриптов сервисов

это до поры, до времени.
И

без написания дистроориентированного (и поддерживающего контроль запуска зависимостей) скрипта запуска/остановки/перезапуска

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

[diesel]

идея автора была убрать огороды из шелл-скриптов, для запуска всего на свете. если оставить скрипты, то от systemd не то чтобы толку есть - в общем-то он просто не отличается тогда от обычного init'а.

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

технически прокладка примерно та же самая. То есть был у нас процесс с id = 1, который init - процесс остался, по-сути делает он тоже самое, только умеет больше.

Если взять "чистую" идею init.d-скриптов, все выглядит очень даже хорошо. Стандартный стартовый скрипт с case и парой тройкой вариантов а-ля restart, start, stop - прост, понятен, читаем, по-юниксовому прекрасен, чего еще хотеть. Проблема в том что стандартный стартовый скрипт сейчас таковым будет только если вы его сами таковым сделаете. Потому как дальнейшее развитие этой красоты уехало в область абсурда.

Оказалось, что для некоторых сервисов какие-то штуки хорошо бы указать в том месте в котором соответствующие процессы стартуют. Ок, указываем. Но пользователю, скорее будет удобно править просто переменные: ок, выносим соответствующие опции в переменные и оставляем переменные в начале стартового скрипта. Но, при установке обновлений стартовые скрипты тоже неплохо было бы обновлять, и то что пользователь там наменял затрется нафиг, ок - выносим пользовательские обновления куда-нить в /etc/system(или как там), тогда хорошо бы и системные дефолты как-то пристроить: нет проблем - /etc/system/default, с кучей надписей "правь не сюда, правь туда"... И вот уже, наши простенькие стартовые скрипты превращаются в огроменный, бесполезный по своей сути фреймворк, для старта процессов. Написанный уже без всякого KISS, обкуренными индусами в Бангалоре, в свободное от песен и плясок время. И в общем-то, systemd здесь очень даже логичен: "давайте оставим фреймворк программистам, а пользователю дадим такой себе DSL с причесанными абстракциями для запуска тех самых сервисов.

C journald тоже примерно понятно - по-сути это попытка сделать pulseaudio для логов Вот сращивание с udev, какая-то ересь про разделы - это уже ребят потянуло явно не туда и не так.

[eddy]

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

Что за фантастика? Это где же так?

[diesel]

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

Что за фантастика? Это где же так?

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

[yars]

Что за фантастика? Это где же так?

Это не фантастика. Это суровая правда. К тому же, помимо выноса переменных в начало скрипта, их выносят в отдельный файл - получаем конфиг, место для которых - /etc. И пусть бы конфиги лежали себе там, так нет - их еще и выносят куда-нибудь, в довольно неожиданное место, как конфиг man в Slackware.

[eddy]

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

Ну, я в линуксе не так давно: года с 2002-го (а то и позже, не помню уже), начинал с ASP7.2. Там такого кошмара не было.

Это не фантастика. Это суровая правда

Доказательство в студию!

конфиг man в Slackware

И каким боком маны связаны с init-скриптами?

[yars]

Никак не связаны. Но что есть, то есть, по умолчанию этот конфиг лежит не в, скажем, /etc/man, а в где-то еще, но посмотреть где, не могу, я с телефона, а навскидку не вспомню. По поводу доказательств - загляните в /etc/rc.d и там найдете конфиг скрипта rc.inet1.