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, довольно быстро умрут естественной в этом случае смертью.

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

да, ты, очевидно, нифига не понял. rm приводился как пример. в место него может быть куча других программ: открой любой configure - там unix-way убивает кучу процессорного времени на загрузку/выгрузку всяких утилит.

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

да, ты, очевидно, нифига не понял. rm приводился как пример.

Значит, неудачный пример.

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

Или, хотя-бы, необходимость тотально выпиливать маленький и тривиальный /bin/sh (который далеко не всегда есть уже таки немаленький bash) в пользу верблюда или пистона. На конкретном примере из системы загрузки.

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

необходимость? конечно необходимости никакой нет... для тех кому не дорого своё время. а кому дорого, уже придумали и сделали новые системы, типа scons, cmake, тот же самый systemd.

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

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

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

Лучше? ХУЖЕ!

При раскрутке системы изначально нет почти ничего (нифига не смонтировано, путей нет, ld не настроен...).

Для раскрутки нужен либо маленький набор статических бинарников с «клеем» для их взаимодействия (BSD или SYSV init), либо бульдозерокомбайн (systemd).

Второе противоречит «Философии UNIX».

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

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

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

речь шла в целом об ущербности систем, требующих таких вот костылей как xargs, если ты не понял.

Все программы и программные среды имеют СВОИ ограничения (в том числе на колическво аргументов/размер ARGV/ARGC...).

И костыли будут ВСЕГДА.

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

и вообще, если параметрами отправлять мегобайты данных в программу - это юниксвейно(что к стати нифига не юниксвей)

Хорошо. Напиши МАЛЕНЬКУЮ утилиту, которая будет читать эти параметры из stdin и делать что тебе нужно.

xargs - такая утилита для запуска ДРУГИХ утилит, которые так делать не умеют.

то к чёртовой матери такой узколобый твой юниксвей нужен

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

Может тебе - туда?

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

Просто успешный результат запуска сервиса при загрузке - не значит что он заработал. В результате мы можем иметь фейл на запуске другого сервиса, который зависит от первого, который мы ошибочно считаем запустившимся. Рестартовать его бесполезно без рестарта первого, но systemd не имеет понятия о том, что произошло. Нотифаи в общем тоже не помогяют, так как работают глючно. Соответственно, особенно если таких сервисов несколько, отлаживать встающую колом систему на загрузке - очень весело.

Можно вот тут раскрыть тему? Чужой опыт всегда интересен.

Просто успешный результат запуска сервиса при загрузке - не значит что он заработал

Это понятно, интересны детали. Какой ресурс предоставляет сервис, как он не запускается итп

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

Не совсем понял этот оборот. Что ожидалось и чего не получилось?

Нотифаи в общем тоже не помогяют, так как работают глючно.

Я правильно понимаю, что речь идет про sd_notify? Что там не работает?

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

Надо разобраться почему так происходит, и мыль баг. Ручки-костыли всегда одинаковы - крон >_<

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

«Философии UNIX»

а нечитабельные шелл-скрипты с кучей костылей, значит, не противоречат философии юникс, да? пусть уж лучше systemd как следует документируют.

кстати, вот тебе на раскурку про бутлоадинг: dracut

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

Я правильно понимаю, что речь идет про sd_notify? Что там не работает?

Я правильно понял, что для корректной работы разных сервисов/демонов предлагается пропатчить их код на предмет включения systemd-специфичного вызова???

Я не спорю, что в поделии Леннарта есть доля сермяжной правды. Вот только, походу, для корректной работы с ним нужно перелопачивать исходники всех over 100500 демонов на предмет взаимодествия с его поделием должным образом.

sergv
()
Ответ на: комментарий от AGUtilities
dracut can generate a customized initrams image which contains only whatever is necessary to boot some particular computer, such as ATA, SCSI and filesystem kernel modules (host-only mode).

dracut can also generate a more generic initramfs image (default mode).

Дальше не читал. initram - костыль.

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

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

Нечитаемые противоречат. systemd не менее костылен и нечитаем.

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

Я правильно понял, что для корректной работы разных сервисов/демонов предлагается пропатчить их код на предмет включения systemd-специфичного вызова???

Да, вполне. Только с тем уточнением, что это может быть нужно только для уточнения фактического состояния процесса. Т.е. глубоко опционально

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

Т.е. глубоко опционально

Вот не факт, однако.

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

Вот хоть этот-же sd_notify.

Отсюда вопрос - уж если без создания лишних сущностей все равно не обойтись никак, то к чему было это Леннартовское «до основания, а затем»?

Обман какой-то откровенный. Или полное непонимание возможных проблем на начальном этапе планирования и реализации.

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

Вот не факт, однако.

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

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

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

И если оно уже вкостылено, то для взаимодействия с бульдозерокомбаином его надо выпилить и вкостылить по-новой «но правильно»? ;-)

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

Как пример - freshclam, который тянет базы для clamd. Старт clamd - просто запуск малофункционального без баз вирусни демона. А то, что freshclam базы сразу получит, а не медленно и печально с 10-ой попытки - тоже не факт. А вот уж если эта парочка корректно не отработала, то стартовать что-то от них зависимое смысла особого и нет.

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

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

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

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

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

Про клам как пример ничего не скажу, т.к. им не пользуюсь. Но если freshclam - отдельная программа которая завершает работу после получения баз, тогда проблема решаема :]

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

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

Дык, оно сейчас, вроде, так и делает. Вопрос в том, как сделать ПРАВИЛЬНО с точки зрения Леннарта, а не через набор скриптов и своих подвязок. И второй вопрос в том, а нужно-ли это делать вообще?

Для тех сервисов, которые умеют правильно d-bus, можно вотчить по факту получения имени на шине.

Сервисов без dbus - пруд пруди. Лишняя сущность и сказывается на переносимости кода.

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

Ну вот писал кто-то что-то (например, тот-же clam). Написал. Портируемо и документировано. Туперь пришел Поттеринг и все опошлил надо переписывать по-новой. Причем непереносимо - без systemd работать не будет. И никто руку на отсечение не даст, что в следующей версии опять переписывать не придется.

Но если freshclam - отдельная программа которая завершает работу после получения баз, тогда проблема решаема :]

Не завершает. Увы. Оно как демон обновления висит в штатном режиме. Или надо по крону пускать и коды возврата отрабатывать.

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

Ну вот писал кто-то что-то (например, тот-же clam). Написал. Портируемо и документировано. Туперь пришел Поттеринг и все опошлил надо переписывать по-новой.

Дык, оно сейчас, вроде, так и делает. Вопрос в том, как сделать ПРАВИЛЬНО с точки зрения Леннарта, а не через набор скриптов и своих подвязок. И второй вопрос в том, а нужно-ли это делать вообще?

Если правильность с т.з. поцтеринга является критерием, то нужно переписать :D Но кому это интересно?

Вообще я хотел бы услышать подробности от slapin. Единственный ожидаемый конструктив в треде

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

Вообще я хотел бы услышать подробности от slapin. Единственный ожидаемый конструктив в треде

Т.е. мой пример не подходит? Жаль. Тогда тоже подожду.

sergv
()

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

qnikst ★★★★★
()

Системный вызов fork — один из самых затратных в ядре, поскольку, не смотря на copy-on-write, для дочернего процесса копируется практически все.

4.2 же. на *nix fork относительно недорогой.

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

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

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

это зависимости от ia32-libs

ttf-fonts зависят от ia32-libs? это где такой бред?

и где ты найдёшь конфиги для ТВОЕГО сервера?

Очевидно, напишу сам, запакую в пакет и поставлю из своего же репозитория. А как иначе раскатывать конфиги на 100500 серверов?

ты не поверишь - сервисы конфигурит. почтовые, СУБД, http и так далее.

Давай конкретику.

скрипт adduser,

Этот скрипт есть везде и в бунте в том числе.

толку с этого графика, и этих сроков, если твоя LTS12 откровенно сырая и недоделанная.

конкретика будет или как всегда?

Какой нафиг сервер, ежели это г-но даже к десктопу ещё не готово??

В том то и дело, что десктоп сделать на порядки сложнее чем сервер. Тут софт сложнее.

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

то-бы админ зубрил Over9000 ключей для useradd и их формат

Facepalm

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

Он не то что бы не подходит, просто обсуждение, как я понимаю, сведется к разговорам о каких-то гипотетических вещах, подробностей которых из нас двоих никто не знает

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

В том то и дело, что десктоп сделать на порядки сложнее чем сервер. Тут софт сложнее.

Тормознутые свистопедрелки не нужны.

Deleted
()
Ответ на: комментарий от AGUtilities

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

дело не в любви к текстовым файлам, а в нелюбви к комбайнам. Комбайн в мире ПО это всегда плохо, по той простой причине, что программист не в состояние охватить всё, особенно в будущем. Да и в настоящем, перезапускающий костыль для mysql лучше получится у mysql, чем у Леннарта, который, AFAIK ни одной СУБД ещё не разработал. Я не прав?

или что для вас unix-way?

каждая программа должна выполнять СВОЮ задачу, и делать это ХОРОШО. перезапускать mysql это не задача init. Задача init - запустить mysqld если он есть и нужен. А уж КАК он запустится - mysqld виднее.

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

не очень понимаю, что вас смущает в bash скриптах? чем они хуже пайтона или перла для инициализации? Тем что их читать проще и удобнее?

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

да, к стати: bash - это не только тормоз прогресса, это ещё и 3-4 тормоза в виде самого себя, а также инструментов которые его используют, таких как make.

бред какой-то. попробуйте собрать например firefox - да, make пожрёт 1000+ метров памяти, и кучу времени, но причём тут bash? Перепешите make на perl'е или пайтоне - ничего не изменится. Жрёт то время и память линкер, а совсем не bash.

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

поясню: да, bash меньше весит и запускается быстрее; да, юниксвейность - это маленькие программы каждая для своего дела. но давайте представим программу, которой нужно, на пример, удалить 10,000 фалйов по списку.

Это говорит лишь о том, что ты никогда не создавал такой программы. IRL для 10К файлов разницы особой нет, ибо мгновенно даже в bash, но и для 10M тоже разницы особой нет, ибо изменения списка/каталога в 10М в любом случае превышает затраты на fork(на несколько порядков). Можешь сам проверить.

Т.е. для маленьких каталогов unlink конечно намного выгоднее fork+unlink, но разницы никакой, ибо файлов мало. А для больших каталогов fork остаётся fork'ом, за то unlink тормозит, и жрёт сотни метров мозгов.

Ну а слухи о какой-то тормознутости баша связаны исключительно с его неправильным применением. К примеру начинающие не учитывают, что ls и звёздочка сортируют файлы, а потому работают дольше (часто НАМНОГО), чем скажем find, ls -U или сишные readdir(3), которые файлы НЕ сортируют.

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

http://pastebin.com/5jc9DdbP

Читаемо ок. Картина не полна без http://pastebin.com/S53b54Uu

Но и тут нет killproc! Где же он? Оказывается ето локальный костыль. Наверное он хорошо выполняет свою единственную функцию ))

Killproc - Send signals to processes by full path name

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

подробностей которых из нас двоих никто не знает

Ну, это как сказать...

Я вот вполне даже навошкался с clamd+freshclam+clamdscan и их обновлением и запуском...

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

xargs (как и find -exec {} +) и без всяких аргументов режет список файлов на строки, которые гарантированно влезают в текущей системе.

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

необходимость? конечно необходимости никакой нет... для тех кому не дорого своё время. а кому дорого, уже придумали и сделали новые системы, типа scons, cmake, тот же самый systemd.

в слаке параллельная загрузка демонов решена уже 100500 лет назад. Ага, на чистом баше, даже без SysV. О каком времени ты говоришь?

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

речь шла в целом об ущербности систем, требующих таких вот костылей как xargs, если ты не понял.

сегодня (уже лет 7 как) необходимости в xargs и нету. В последний раз ограничения длины командной строки встречалось мне в Slackware 10.2. В современном bash'е можно сделать строку ЛЮБОЙ длинны. Лишь-бы памяти хватило.

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

и вообще, если параметрами отправлять мегобайты данных в программу - это юниксвейно(что к стати нифига не юниксвей)

почему - нет?

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

а нечитабельные шелл-скрипты

почему они «нечитаемы»?

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

ttf-fonts зависят от ia32-libs? это где такой бред?

прямо от алсы: http://packages.debian.org/squeeze/ia32-libs а вот шрифты видимо косвенно. Смотри сам, мне лень.

Очевидно, напишу сам, запакую в пакет и поставлю из своего же репозитория. А как иначе раскатывать конфиги на 100500 серверов?

речь про 100500 РАЗНЫХ серверов.

Давай конкретику.

поставь что-нить из вышеперечисленного в Debian

Этот скрипт есть везде и в бунте в том числе.

в бубунте не знаю, а в CentOS таки нет. Пруф я тебе в том году уже дал.

конкретика будет или как всегда?

конкретику ищи на этом форуме. она есть.

В том то и дело, что десктоп сделать на порядки сложнее чем сервер. Тут софт сложнее.

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

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

Ето Gnu/Linux CLI. Только стандартизация, только хардкор.

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

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

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

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

Смотри сам, мне лень.

опять сливаешь

речь про 100500 РАЗНЫХ серверов.

очевидно, что в этом случае будет 100500 разных пакетов с конфигами

поставь что-нить из вышеперечисленного в Debian

понятно, опять слив

в бубунте не знаю, а в CentOS таки нет. Пруф я тебе в том году уже дал.

есть

конкретику ищи на этом форуме. она есть.

и опять слив

потому как например создатели бубунты особенно не заморачиваются например установкой и настройкой разных СУБД и почтовиков

а на кой это, например, на hdfs сервере ?

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

сегодня (уже лет 7 как) необходимости в xargs и нету. В последний раз ограничения длины командной строки встречалось мне в Slackware 10.2. В современном bash'е можно сделать строку ЛЮБОЙ длинны. Лишь-бы памяти хватило.

4.2

$ find . -type f |wc -c
2462820
$ ls `find . -type f`|wc -l
-bash: /bin/ls: Argument list too long
0
$ bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ free
             total       used       free     shared    buffers     cached
Mem:       8159628    7226072     933556          0     180208    3980496
-/+ buffers/cache:    3065368    5094260
Swap:      7811064          0    7811064
$ cat /etc/issue.net 
Debian GNU/Linux 6.0
sergv
()
Ответ на: комментарий от vasily_pupkin

http://pastebin.com/5jc9DdbP

Читаемо ок. Картина не полна без http://pastebin.com/S53b54Uu

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

Во вторых, чем тебе не понравился второй скрипт? присвоить кучи переменным кучу значений можно как-то иначе? В POSIX SHELL нельзя. В баше можешь юзать массивы, в т.ч. и ассоциативные. Синтаксис конечно своеобразный, но всё работает.

Но и тут нет killproc! Где же он? Оказывается ето локальный костыль. Наверное он хорошо выполняет свою единственную функцию ))

что за killproc?

Killproc - Send signals to processes by full path name

типа pkill+pgrepчто-ли?

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

в бубунте не знаю, а в CentOS таки нет. Пруф я тебе в том году уже дал.

есть

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

а на кой это, например, на hdfs сервере ?

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

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