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

★★★★★

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

aptitude, как ни странно, позволяет сделать почти то же самое

как?

в debian испокон веков существует файл /etc/apt/apt.conf.d/01autoremove, в котором говорится, что ядра и модули удалять автоматически не надо.

Ну вот у меня одна из убунт сама говорила после загрузки в свежее ядро что старые можно apt-get autoremove. К сожалению я её недавно снёс.

А так это есть:

APT 
{ 
  NeverAutoRemove 
  { 
    "^firmware-linux.*"; 
    "^linux-firmware$"; 
    "^linux-image.*"; 
    "^kfreebsd-image.*"; 
    "^linux-restricted-modules.*"; 
    "^linux-ubuntu-modules-.*"; 
    "^gnumach$"; 
    "^gnumach-image.*"; 
  }; 
true_admin ★★★★★
()
Ответ на: комментарий от true_admin

как?

там где apt-get принимает имя пакета, aptitude принимает паттерн, подробнее - в aptitude reference guide/Search patterns/Search Term Reference

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

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

А так это есть:

ну так это как раз причина того, что для ядер autoremove не работает.

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

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

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

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

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

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

все дело в том что в ней нет команды autoremoveoldkernels?

да. Я внезапно обнаружил старых ядер гига на три. Собстно, aptitude тут ни при чём, это косяк каноникал. Могли, например, linux-image-generic сделать таким чтобы он зависел от текущего и предыдущего ядра. Тогда проблемы бы решились.

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

текущее и предыдущее оба могут быть нерабочими, что тогда делать?

«Текущее», «предыдущее» и «еще одно, старое как говно мамонта».

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

текущее и предыдущее оба могут быть нерабочими, что тогда делать?

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

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

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

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

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

Текущее ядро это то которое таки работает.

см. выше - у всех могут работать разные «последние» ядра, поэтому linux-image-generick придется каждому делать свой.

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

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

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

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

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

А, понял о чём ты. Да, в рамках пакета с фиксированными зависимостями это не решается.

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

товарищ, у вас slackware?

Не только, но есть и slackware.

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

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

Ещё один админ локалхоста, да? :)

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

Зависит от работы.

да.
но я все-же говрил не о разработчиках дистрибутивов.

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

Первый раз слышу что Windows это линукс! Может на дистровоче покажете?

У тебя голоса в голове?

Нет.
Это я с местным норкоманом общаюсь

PaulCarroty>RHEL не является популярным дистрибутивом. Шиндовс XP является самым популярным дистрибутивом

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

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

Дану!
А если производитель проприетарного софта их делает только под Ubunte и RHEL?
Я как раз с таким сейчас и работаю.

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

Первый раз слышу что Windows это линукс! Может на дистровоче покажете?

Это я с местным норкоманом общаюсь

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от grim

Да ладно тебе, я и после «семисотки» иногда такие простыни тут выписывал. Правда, пальцы путались, поэтому «очепяток» много было. И мысли путались.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от grim

Нет, у тебя таки видимо голоса в голове.

Первый раз слышу что Windows это линукс!

Ccылку на мою реплику, иначе слив защитан.

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

Да какие проблемы удалить ручками старое ядро, всего то в двух местах ?

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

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

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

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

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

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

серьезный софт велосипедит собственные watchdog'и для поднятия умерших демонов

софт который плодит демонов и сам же их перезапускает если не может достучаться? Аххах) И это серьёзный софт?

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

Единственное что там было сказано адекватного это то, что нужно лечить причины крашей. Остальной высер про ненужность watchdog'а и прочее это либо ламерство либо отсутствие реального опыта.

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

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

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

_Никто_ не пишет без ошибок.

датычо!? Невероятно.

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

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

а не с красными глазами запускают упавшие сервисы по ночам.

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

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

Я не понял к чему ты это написал, но ты тронул моё сердце

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

Ну обновил ты пакет, второстепенный, прилетел с ним .service, например, создающий циклическую зависимость. После чего, спустя время железяка от тебя в 600 км ребутнулась, а ssh не поднимается... лезешь, а оно connection refused.

Да, в systemd это можно отладить через передаваемые параметры в конфиге ядра, методом исключения найдешь мешающий сервис, сложив все маты. в sysvinit'е такого быть не могло. Поэтому при начале пользования этим появляется ощущение хрупкости. Далее, если демоны не написаны с использованием нотифаев от systemd, таблица зависимостей между процессами - самообман, и должны быть написаны средства, обеспечивающие работу сервисов, как и в sysvinit, но система рабоает при этом нестабильно (то есть если подход sysvinit - грузимся полюбому, пофиг если что померло по дороге, то systemd - вот эта хренотень по зависимостям не прогрузилась, подождем, не дождались - значит нехрен и грузиться дальше. Помню как из-за логгера и alsa-state у меня не появлялись getty). Это по опыту своему годичной экспулатации этого чуда на embedded устройствах. Большая часть времени при работе с systemd уходит на создание костылей и подпорок для того, чтобы оно работало. Порог вхождения для создания надежной системы значительно выше, чем при использованиие sysvinit. В основном это наверное из-за подхода «лучше совсем не загружать систему с битыми сервисами, а то мало ли что», ну и плюс кривые зависимости. Но вроде как готовить научились это дело, потому как чужого софта, не проходящего через меня там нет, и я могу гарантировать, что все сервисы будут правильными. Ну там еще из мелочей, активация по dbus, если оформлять при этом сервис на аппликуху с Type=dbus работает странно и бажно, непонятно вообще зачем оно надо. То есть тонкостей очень много, переусложнено все, мне кажется.

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

Ccылку на мою реплику,

Популярно про systemd и Леннарта Поттеринга (комментарий)

PaulCarroty>RHEL не является популярным дистрибутивом. Шиндовс XP является самым популярным дистрибутивом

иначе слив защитан.

Писец, как я испугался!
Выйдете из под влияния веществ - посмеётесь :)

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

Например, знаешь как в убунте удалить старые ядра?

Переусложнённо и с ошибкой. Можно вот так:
dpkg -l linux-\* | grep ^ii | cut -d\ -f3 | grep -v $(uname -r | cut -d- -f1,2) | grep [0-9] | xargs sudo apt-get purge

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

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

потому это надо в init запихивать?

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

ты не понял о чём речь. В ТС написал что теперь меньше форков нужно. Но основные тормоза не ими вызваны.

всё я понял:

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

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

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

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

дырявый

Проблемы безопасности решаются не так

и нестабильный сервис

Падение раз в месяц это стабильность или нестабильность?

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

Да, это так. Сложный софт всегда идет с watchdog'ом в комплекте (типичный пример — база данных). Если ты этого не замечал, то это говорит об отсутствии у тебя реального опыта.

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

например, создающий циклическую зависимость

вот эта хренотень по зависимостям не прогрузилась, подождем, не дождались - значит нехрен и грузиться дальше

Это по опыту своему годичной экспулатации

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

этого чуда на embedded устройствах

embedded

P_P

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

этого чуда на embedded устройствах
embedded

P_P

Что тебя удивило - то, что ретивые фанаты systemd уже сделали как минимум один встроенный дистр на systemd?

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

Падение раз в месяц это стабильность или нестабильность?

нестабильность

Да, это так. Сложный софт всегда идет с watchdog'ом в комплекте (типичный пример — база данных). Если ты этого не замечал, то это говорит об отсутствии у тебя реального опыта.

это не говорит о том, что такая НЁХ нужна в init'е.

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

Удивляюсь тому, что нынче называется ембедеддом :D

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

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

Чтобы каждый демон не изобретал свой собственный велосипед как происходит сейчас.

потому ВСЕМ будут выдавать велосипед от Леннарта? А если у меня не падают сервера раз в месяц? А если и падают, то исключительно из-за моих кривых рук?

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

встроенный дистр на systemd

Брр... Какой же это, нафиг, embedded, если туда влезает целый дистрибутив, да еще и с поцтериногоговном?

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