LINUX.ORG.RU
ФорумTalks

Популярно про systemd и Леннарта Поттеринга


4

3

После нескольких обсуждений и многочисленных критических высказываний в адрес systemd, у меня сложилось впечатления, что не все понимают в вопросе, о котором спорят. Как правило, против Поттеринга приводятся несущественные аргументы или эмоции, тогда как все аргументы уже давно им были высказаны безаппеляционно и по-существу (http://0pointer.de/blog/projects/why.html). Остановимся вкратце на killer-фиче «Socket-based Activation».

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

1)Init запускает bash, bash интерпретирует файл /etc/init.d/rsyslogd

2)Запускается бинарный файл /usr/sbin/rsyslogd

3)rsyslogd инициализирует себя, и в момент готовности к работе он делает fork. С этого момента вся деятельность происходит в дочернем процессе, а родительский немедленно умирает. Это делается для оповещения процесса bash, ожидающего возврата управления.

Если не обращать внимание на чудовищный по накладным расходам пункт 1, то, как видно, остается еще один замедляющий загрузку момент.

Системный вызов fork — один из самых затратных в ядре, поскольку, не смотря на copy-on-write, для дочернего процесса копируется практически все. Использование его всего лишь для оповещения — это как стрельба из пушки по воробьям. Здесь как нельзя лучше подходит выражение «broken by design». Такой способ запуска демонов считается классическим. Unix-way никто не отменял, просто глупо холить и лелеять подобные дурацкие традиции.

В systemd пункт 1 отсутствует полностью, а вместо fork() используется простая и незатратная посылка сообщения через сокет с помощью sendmsg.

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

★★★★★
Ответ на: комментарий от drBatty

ради большей переносимости

О нет, нет.. Переносимость скриптов инициализации? Забудьте.

что за killproc?

Отличный вопрос, который возникает когда нужно фиксить/писать скрипты инициализации для разных дистрибутивов. Это такая инновация в opensuse. Есть еще daemon (RH), start-stop-daemon (Gentoo,BB,Debian?), варианты с pkill, lsof итд

Во вторых, чем тебе не понравился второй скрипт

Он практически нечитаем. Там легко налажать. Там невозможно заметить факап.

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от drBatty

это lsпроблема ИМХО. у меня сейчас просто каталогов таких нет...

$ bash --version
GNU bash, версия 4.2.24(1)-release (i686-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Это свободное программное обеспечение; Вы можете бесплатно изменять и распространять его.
There is NO WARRANTY, to the extent permitted by law.
$ find . -type f |wc -c
10793880
$ echo `find . -type f`|wc -c
10797510
$ /bin/echo `find . -type f`|wc -c
bash: /bin/echo: Слишком длинный список аргументов
0

Вывод - список аргументов нелимитирован только для builtin команд.

Так-что 4.2.

Да и будь мужиком - скажи «cd /» :-)

sergv
()
Ответ на: комментарий от drBatty

есть симлинк adduser -> useradd. Впрочем, как всегда...

И?

[root@cloud-db05 ~]# lsb_release -a
LSB Version:    :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Release:        5.4
Codename:       Tikanga
[root@cloud-db05 ~]# ls -l `which adduser`
lrwxrwxrwx 1 root root 7 Feb 25  2011 /usr/sbin/adduser -> useradd

а поддержка hdfs уже есть в убунте минимал?

Конечно. Добавляем репозиторий cloudera и одной командой ставим пакеты.

Reset ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

- когда сервис использует dbus-активацию - когда зависимость не явная, например сервис для своей работы требует не просто запущенный сервис, а чтобы он перешел в определенное состояние. Например, GSM модем должен зарегистрироваться в сети, подняться _живая_ ppp-сессия (нужно удостовериться), и тп. - когда нужно, чтобы медленно запускающийся сервис, от которого все зависит, не стопил загрузку системы, но при этом нужно, чтобы реально все начинало работать только после того, как он поднимет флаг.

Часто удается добиться помощи от systemd через врапперы, но в некоторых случаях приходится писать свою логику. Бывает даже, нужно обходить systemd. Просто элементарно жалко, что есть вроде как встроенные механизмы, но напрямую удается ими воспользоваться в меньшинстве случаев.

Если в случае с clamav есть возможность внешними средствами определить готовность к работе, можно воспользоваться скриптом, запускаемым как отдельный сервис, и выставляющим готовность согласно признаку. И все зависящее от clamav делать зависимым от такого сервиса. А сам сервис, из которого скрипт запускается, делать зависимым от сервисов clamav.

slapin ★★★★★
()
Ответ на: комментарий от slapin

подняться _живая_ ppp-сессия (нужно удостовериться), и тп.

Это похоже на NetworkManager-wait-online.service

Бывает даже, нужно обходить systemd.

А что там с notify за проблемы были?

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

О нет, нет.. Переносимость скриптов инициализации? Забудьте.

в любом случае, это НЕ bash. Потому ваши претензии не имеют под собой обоснования. Да, POSIX SHELL это достаточно неудобный и слабочитаемый ЯП, в котором не хватает многих привычных идиом (тех же массивов, и даже нет вменяемых операций для ветвления по условию, конечно, довольно глупо вызывать внешнюю программу для того, что-бы выяснить, что X больше 17). Да и с совместимостью - вроде как /bin/sh есть везде, test вроде как тоже, но вот как поведёт себя этот ваш test IRL - предсказать решительно невозможно. Часто даже нельзя сказать, /bin/test это, или встроенная команда.

Отличный вопрос, который возникает когда нужно фиксить/писать скрипты инициализации для разных дистрибутивов. Это такая инновация в opensuse. Есть еще daemon (RH), start-stop-daemon (Gentoo,BB,Debian?), варианты с pkill, lsof итд

ну... что поделать. Патрег такого не одобряет.

Он практически нечитаем. Там легко налажать. Там невозможно заметить факап.

я же говорю - автор думал за «совместимость» (мне ТОЖЕ непонятно чего с чем), а про это не думал. Вообще говоря, кривой код можно писать на ЛЮБОМ ЯП. И на скриптах это получается особенно хорошо, ибо думаешь - временный костыль, а на практике этот костыль работает десятки лет, ибо наворачивать systemd никто не хочет. Вот... Поттеринг сподобился. Пока получается НЁХ как и всегда.

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

ну Linux вообще изначально написан любителями, а уж _потом_ пропатчен и перепилен профессионалами (часто - теми-же самыми людьми)

Что думают все отцы - без понятия, а Патрег думает, что если скрипт 1993го года сейчас нормально работает, то нет смысла его переписывать. Мало того, если какому-то скрипту нужен tar 1999го года, то проще оставить в дистре этот tar, чем ломать голову, как переписать этот скрипт (к тому же, другие скрипты тоже придётся переписать).

drBatty ★★
()
Ответ на: комментарий от sergv

Вывод - список аргументов нелимитирован только для builtin команд.

ну выходит что так. Хотя я как-то ЕМНИП и 100Мб список передавал tar'у - bash пожрал где-то 100Мб, но отработал таки. Возможно tar такое умеет...

Да и будь мужиком - скажи «cd /» :-)

после того, как у меня в бекапе файлы затерялись, я именно так и делаю ;)

drBatty ★★
()
Ответ на: комментарий от Reset

есть симлинк adduser -> useradd. Впрочем, как всегда...

И?

разница между скриптом в 300 строк без комментариев и симлинком тебе непонятна? Ну тогда извини...

Конечно. Добавляем репозиторий cloudera и одной командой ставим пакеты.

так и запишем - нету.

drBatty ★★
()
Ответ на: комментарий от drBatty

Опять слив? Объяснить зачем на абстрактном сервере в вакууме нужна БД и почтовик значит не можешь? Ты хотя бы раз что-нибудь адекватное и конкретное скажешь? Пока от тебя только сплошное 4.2 и «не знаю», «говорить не буду» ...

Reset ★★★★★
()
Ответ на: комментарий от vasily_pupkin

короче цепочка сервис1 зависит от сервис3 сервис2 зависит от сервис3

сервис3 не смог запуститься, но systemd этого не понял запустился сервис2, так как он использует сервис3 только когда приконнектился к серверу, а сейчас ppp лежит, поэтому не можем построить зависимость в терминах systemd. сервис1 запустился, но зафейлился, так как не смог связаться с сервисом 3.

В systemd это выглядит так: сервис1 - фейлед сервис2 - работает сервис3 - работает

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

Иначе, делать свои собственные костыли. sd_notify теоретически должен работать, но на практике это не так. Возможно он работает из сишных программ, но из шелл-скриптов, запущенных из подпроцессов управляемого процесса (например из /etc/ppp/ip-up.d/01connected) не работают. Что лишает sd_notify полезности в нашем случае.

Type=dbus работает слишком волшебно, показал в нашем случае плохо предсказуемое поведение, и оно менялось от версии к версии systemd. Может в последних версиях и починили уже, но у нас продукт уже. Поэтому используем свои собственные механизмы поверх dbus и dbus-активацию, там где это критично, без использования sd_notify и Type=dbus, с оберткой для проверки состояния процессов.

То есть основной selling point systemd, из-за которого было принято решение его использовать, был пущен коту под хвост. А так - работает скотинка, инит как инит. Если трезво оценивать ситуацию, при правильной настройке ничем не хуже sysvinit. Ну, хрупковато немного, но для эмбедки и своей песочницы вполне сойдет.

А что касается баг репортов - версии systemd устаревали быстрее, чем мы успевали их апдейтить, в конкретных ситуациях часто сложно было понять чей это баг, сейчас, когда это уже ясно, поезд уже давно ушел и далеко. systemd довольно опасно апдейтить - там одно чинят, другое ломают, в основном мемлики. Стабильных поддерживаемых версий у них нету. То есть если апдейтишь - ССЗБ, и если не апдейтишь - ССЗБ. Бакпортить патчи часто бесполезно - оно очень часто уже переписано оказывается в том месте, где баг был. Остановились мы на тщательно оттестированном месте, уняли немного journald от выжирания памяти. В более поздних версиях он стал жрать еще больше, и до сих пор в нем лики вылавливают. После этих вот мучений зареклись пока systemd апдейтить. Вот запилят обход journald - тогда снова оттестим.

slapin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Ситуация: имеем сервис с dbus-активацией. С момента обращения к сервису до захвата сервисом имени на шине проходит 10 секунд. (python, блин). Там стоит хитрая проверка, что мы можем иметь только один сервис на шине. Если нет .service, нет проблемы, сервис запускается, методы запускаются, сигналы слушаются, все ништяк. создаем .service файл. Type=dbus, имя на шине правильное. Сервис запущен из-за запуска приложений, работающих с ним. говоришь systemctl status имясервися.service - оно говорит, что оно не запущено. Почему? Разбираться было лень, если кто проверит с последними версиями systemd, было бы интересно узнать что там.

slapin ★★★★★
()
Ответ на: комментарий от slapin

Возможно он работает из сишных программ, но из шелл-скриптов, запущенных из подпроцессов управляемого процесса (например из /etc/ppp/ip-up.d/01connected) не работают

Ну как бы да. Оно расчитывает, что нотифи будет слать то, что оно считает за mainpid.

Может в последних версиях и починили уже, но у нас продукт уже
Type=dbus работает слишком волшебно

Поинт понятен. Действительно, там щас активное перепедаливание, и периодически леннарт обнаруживает что fedora != все остальные линаксы. Ну и я вспомнил, что некоторые базовые патчи закоммитили месяц назад, и войдут в основное дерево d-bus в лучшем случае к следующему релизу (%

vasily_pupkin ★★★★★
()
Ответ на: комментарий от slapin

Если активация средствами d-bus, то в сервисе d-bus должен быть указан соотв. сервис systemd. Ну и, как написал, там для пользовательской сессии патч только-только приняли в основное дерево. Так что там реально какая то ботва могла быть на тот далекий момент

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Reset

Опять слив? Объяснить зачем на абстрактном сервере в вакууме нужна БД и почтовик значит не можешь?

значит НЕ НУЖНЫ?

Речь о том, что в Debian имеются удобные и быстрые средства, которые помогают быстро и просто развернуть почтовый сервер, или сервер СУБД(или ещё что). И насколько я знаю, бубунтовцы эти средства НЕ развивают, и по этой причине убунту ставить нет смысла (на сервер), ибо разворачивать придётся либо самому, либо надёргав костыли из Debian'а. В любом случае, бубунта не нужна.

Кроме того, развитие убунты == развитие десктопа - над ядром они не работают, над серверным ПО тоже, только над десктопными приложениями (юнити например). Я НЕ говорю, что это плохо само по себе, я говорю, что это бесполезно для серверов.

drBatty ★★
()
Ответ на: комментарий от drBatty

значит НЕ НУЖНЫ?

В общем случае - нет

Речь о том, что в Debian имеются удобные и быстрые средства, которые помогают быстро и просто развернуть почтовый сервер, или сервер СУБД(или ещё что).

В убунте есть ровно те же средства, дергать ничего не надо.

Кроме того, развитие убунты == развитие десктопа - над ядром они не работают, над серверным ПО тоже, только над десктопными приложениями (юнити например). Я НЕ говорю, что это плохо само по себе, я говорю, что это бесполезно для серверов.

Еще раз. У убунты поддержка 5 лет. У дебиана - 3. Убунта выходит по графику раз в два года и с относительно свежим софтом, поэтому можно что-то планировать. Дебиан выходит раз в пятилетку абы как и с протухшим на два года софтом.

Reset ★★★★★
()
Ответ на: комментарий от Reset

значит НЕ НУЖНЫ?

В общем случае - нет

тогда и всябубунта-минимал в общем случае не нужна (:

В убунте есть ровно те же средства, дергать ничего не надо.

смысл в бубунте тогда, если там всё из деба, кроме юнити с апстартом, которые на сервере и не нужны?

Еще раз. У убунты поддержка 5 лет. У дебиана - 3. Убунта выходит по графику раз в два года

Ещё раз - убунта 12 не готова даже для быдлохрома.

вот на вскидку Вырвиглазные шрифты в google chrome www.linux.org.ru/gallery/screenshots/8369651 Что делать с flash в Chrome?

О каком Ынтерпрайзе и google тыт тут рассказываешь?

drBatty ★★
()
Ответ на: комментарий от drBatty

смысл в бубунте тогда, если там всё из деба, кроме юнити с апстартом, которые на сервере и не нужны?

Ответил уже. Ты читать не умеешь?

Ещё раз - убунта 12 не готова даже для быдлохрома.

На это я уже ответил выше.

О каком Ынтерпрайзе и google тыт тут рассказываешь?

Рассказываю о том, что есть, а ты можешь и дальше 3.1415здоболить.

Reset ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

в inittab пишешь тупо

::sysinit:/etc/linuxrc

а в /etc/linuxrc десяток строк с необходимыми действиями - примонтировать что надо, настроить ядро, загрузить модули, запустить демоны. И золотой ключик у тебя в кармане. Быстрее, проще и надёжнее сделать не получится. А за systemd в такой железке надо сразу убивать.

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

Stanson ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

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

Школота, иди уже учись, наконец! Леннарт-то хоть бабло или другие ништяки получает за свои говноподелия и потуги их пропихнуть во все дыры. А ты за просто так клоуном работаешь, по глупости :)

Не, ну не могут же быть поголовно все поттерингофилы настолько тупыми... Соответственно, логично предположить, что только тупорылый школьник может быть поттерингофилом. Это всё объясняет.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

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

Сгинь школоло.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

несколько демонов в связке с iptables

О да, в iptables в каждой версии меняются ключики, поэтому каждый раз надо все скрипты переписывать.

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

И да, обновлять прошивку надо, сцуко, ажно кажный день по 2 раза.

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

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

Stanson ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.