systemd 246

И в контейнерах всё равно не используется система инициализации вообще.

Согласен. Если бы Леня сделал свое творение модульным, в его сторону летело бы гораздо меньше фекалий.

Тогда бы вместе The One Ring получился просто ещё один init. Никто бы и не заметил.

запуск сервисов-зависимостей

/bin/service1 && /bin/service2 && ...

перезапуск упавшего сервиса

while :; do /bin/service1 ; done

Я бы посмотрел, как ты это реализовал с помощью полутора строк на баше.

Баш это полноценный ЯП, на нем можно что угодно реализовать.

/bin/service1 && /bin/service2 && …

А теперь предположим, что service1 и service2 запускаются по минуте каждый (но при этом процессор не является бутылочным горлышком), service2 требует сеть, а service3 зависит от них обоих. Кстати, перезапускать их нужно строго в обратном порядке. А ещё service1 торчит голой жопой в Интернет, и его бы неплохо засунуть в суровую песочницу, а service2 ограничить до 50% CPU, потому что ну вот так, жопой его писали. Твои действия?

while :; do /bin/service1 ; done

Предположим, service1 демонизируется. Твои действия?

Баш это полноценный ЯП, на нем можно что угодно реализовать.

Но далеко не всегда с помощью полутора строк.

конечно, лучше же 20 раз написать cat/grep и путя, чем написать journald и юнит. ах ты ж мамкин гений!

Да просто grep отлично катит. Понимаешь, что проблема унификации логов – это проблема унификации логов, не больше.

предвижу фразу: «ты неосилил таб!!1»

Как будто, с sudo он работает. И если в /var/log/ можно добавить себе +r и [tab] будет катить. То с journalctl – не, нет.

Ну вот твоя писанина в данном треде — это однозначно демагогия вперемежку с хамством.

Т.е. мнение о том, что systemd - разжирел, это у нас уже демагогия? очень интересная позиция. Но ты ведь у нас прям светило. Самоуверенное донельзя.

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

Лучшего подарка ты мне даже сделать не мог. Не придется отвечать на самоуверенную болталогию в ответ на мои сообщения. Но уж про твои я - не забуду. Уж поверь. Ты у меня встал в один ряд с reactos-ом.

while :; do /bin/service1 ; done

Т.е. инит-скрипт не вернёт управление после запуска вообще никогда? Классная идея!

/bin/service1 && /bin/service2 && ...

Подожди, но по твоей логике зависимости надо тоже в бесконечных циклах запускать, вдруг они тоже упадут? Кроме того, от сервиса могут зависеть несколько других, как предполагается отслеживать все эти связи? А полученного монстра на bash ты потом копипастить с небольшими изменениями в каждый сервис-файл будешь?

Как вообще можно быть системным администратором ОС, если херовина, которую ты администрируешь имеет 245 версий и в каждой что-то сделано иначе, чем в предыдущей? Это же адский ад.

Они были отдельными сущностями с самого начала. Доброе утро.

Но можно ли их использовать отдельно?

А полученного монстра на bash ты потом копипастить с небольшими изменениями в каждый сервис-файл будешь?

Сервис-файлы это переусложнение, /etc/rc.bash хватит для всех сервисов.

Считай, что это 2.46. less ты же как-то пользуешься, а там уже, наверное, под 800 номер версии.

Вполне. Но это на самом деле не имеет никакого значения: даже между отдельными сущностями могут быть жёсткие зависимости. Ты же не жалуешься, что Firefox жёстко зависит от GTK?

Имеет значение лишь то, можно ли их заменить на аналогичные.

А теперь предположим, что service1 и service2 запускаются по минуте каждый

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

Однако, выяснилось, что революции не произошло, скорость загрузки с внедрением systemd изменилась незначительно.

У Вас логика сломалась

Нет, конечно.

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

Следовательно, в моём случае личность автора не важна (т. к. можно просто проверить валидность инструкции, которая инвариантна относительно количества погонов на её авторе), а в твоём случае важна, т. к. конструктивно валидность заявления никак не проверяется и остаётся только верить автору.

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

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

Да вот нет.

Да вот да. В случае железных серверов разницы вообще нет, т.к. инициализация железа занимает много больше времени чем загрузка оси. В случае виртуалок в большинсте сценариев отрабатывает связка «получить сеть, поднять апач, поднять томкат» и выгоду от паралельного запуска надо под микроскопом разглядывать. Либо «поднять докер, поднять кубернетес» и дальше уже оркестратор всё запускает.

Вот и получается, что на синтетических тестах польза видна, а в реальной реальности — не очень.

разница начинает быть очень и очень заметной.

Поделитесь историей из личного опыта?

день админа обосрал своей новостью

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

Реальных примеров из практики, мы, само собой, не дождемся.

Поделитесь историей из личного опыта?

Поделюсь, конечно. Мир не ограничивается докером и кубернетесом.

Есть (был) вот у меня сервер, на котором крутится несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие, поэтому из кубера вынесены (не моё решение, я бы прикрутил к кластеру провиженинг PVC и дело с концом). Ну каждый стартует там секунд по 30-100, а раньше они при этом ещё и общались друг с другом. Сервисов всего порядка десяти штук. Удачи с последовательным запуском.

Ну и заметка на полях — если бы тот же кубернетес стартовал поды по порядку, ты бы тоже кричал «параллельный запуск не нужен, последовательного хватит всем»? :)

Есть (был) вот у меня сервер, на котором крутится несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие

Ну кто-бы сомневался-то. Уже даже и удивления - не вызывает, что то, что у тебя крутиться такого качества, что даже дунуть страшно. Но это - лирика. ну стартуют долго, и? В чем проблема распаралеливания? Ах - надо программировать научиться? зачем, если можно взять монстра, в котором от изначальной идеи, параллельного запуска, уже мало что осталось и понапихать туда криворукие «хрупкие» поделия. Никто не говорит, что идея systemd изначально ненужное барахло. Люди говорят, что он разжирел и принял в себя кучу ненужного. Но ты, как светило, которое за своим светом не видит уже совсем ничего, никак не в состоянии это осознать. У тебя одно собственное мнение имеет значение. Нимбанутое.

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

Ну да, как послушать ЛОРовцев, так их софт не течёт, не падает и потребляет отрицательное количество памяти :) Оно и понятно, 5.1здеть — не мешки ворочать.

В чем проблема распаралеливания? Ах - надо программировать научиться?

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

P. S.: макском, почини игнор.

макском, почини игнор

linux.org.ru##.comment > .msg:has(.sign:has-text(/DrRulez/i))

Есть (был) вот у меня сервер,

Железный или виртуальный? Если железный, то сколько времени проходило между админ нажал на кнопку включения и «сервере сделал вжух-вжух, можно приступать к загрузке OS»?

несколько сервисов на пхытоне и чём-то таком на JVM … каждый стартует там секунд по 30-100

Жуть. В этой ситуации, параллельный запуск, конечно, оправдан.

если бы тот же кубернетес

А я разделяю задачи инициализации системы и оркестрации микросервисов, не валю всё в одну кучу.

А теперь предположим, что service1 и service2 запускаются по минуте каждый (но при этом процессор не является бутылочным горлышком), service2 требует сеть, а service3 зависит от них обоих. Кстати, перезапускать их нужно строго в обратном порядке

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

строго говоря, в sysvinit запилили insserv и startpar

Читай «костыли на соплях». Но хорошо, допустим. Речь не о sysvinit, а о нужности параллельного запуска.

А зависимости systemd сделаны, мягко говоря, через одно место.

Раскрой мысль.

Ну да, как послушать ЛОРовцев, так их софт не течёт, не падает и потребляет отрицательное количество памяти :) Оно и понятно, 5.1здеть — не мешки ворочать.

Так я так и не услышал, что там у тебя в реальной практике так требует полного функционала systemd? Только какие-то сказки про абстрактное кривонаписанное барахло. И меня реально нисколько не удивляет, ни барахло в комплекте с тобой, ни применение тобой монстра для управления подобным хозяйством. Примеров - реальных, а не «несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие», мы так и не увидели. Что, разумеется, нисколько не удивляет, учитывая, кто этоим всем управлял/управляет. Да-да. Я имею в виду именно - тебя. Наверное, для исправления ситуации нужно начать прислушиваться к мнениям других людей, а не только самоуверенный нимб носить.

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

тут - вообще без комментариев. Я и говорю - раздвоение личности. вам надо срочно на Загородный проспект в городе-герое Москве. Там вам - помогут.

https://blog.darknedgy.net/technology/2020/05/02/0/index.html - ну вот, например, статья. И вот к какому выводу там приходят:

What the Requisite= example vividly shows is that systemd dependencies are not additive, nor are they constraints, invariants or ‘checks’ of any kind that one might intuitively expect. Combining dependencies overrides and supersedes behavior rather than enforcing more constraints, since all of these dependency directives are coarse-grained ad hoc instructions with numerous side effects that range from events, relationships, and ordering to their propagation effects

Железный или виртуальный?

Арендованная виртуалка.

А я разделяю задачи инициализации системы и оркестрации микросервисов, не валю всё в одну кучу.

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

Иначе получается «шутка-самосмейка» — кольцевой аргумент, который обосновывает сам себя, только если изначально принять его на веру.

Примеров - реальных, а не «несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие», мы так и не увидели.

Может тебе ещё и исходники продукта с прошлой работы притащить?

Так я так и не услышал

Ты сначала определись, что ты хочешь услышать. А то в каждом своём сообщении (которое я почему-то всё ещё вижу) ты почему-то «хочешь услышать» совершенно разные вещи. Отличная тактика, но нет.

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

К чьим мнениям-то? Хамящего юникс-вытирана с ЛОРа? Насмешил.

И да, видишь ли, ситуация не требует исправления. У меня всё замечательно работает.

А зачем?

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

А зачем?

Потому, что это - логично. Ты знаешь, что такое - логика?

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

Т.е. по вашему выходит, что инициализация системы и ее дальнейшее управление, это одно и тоже? Как интересно. Давайте тогда понапихаем все это барахло, скажем, в grub2. А что - вполне себе идея, с такой-то «божественной» и «верной» идеологией, как у вас, mon chere. Можно еще дальше пойти. И позапихать все в efi. Единственно, конечно, вас не поймут производители материнских плат и тут уж точно они наймут крепких санитаров, для успокоения буйнопомешаных на монолитных системах типа systemd.

эт чё за системд?

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

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

С иными системами инициализации такого никогда не было, фишка systemd. Ну да ладно.

Вербальный лог на экране ничерта не говорит. A stop job is running for Session c1 of user ntfs (1min 30s). Ну да ладно.

Загуглил на тему «как понять, WTF». И вы таки удивитесь, ответы - включить логгирование всего, storage=prsistent, и написать в автозагрузку скрипт который будет сохранять dmesg в файл чтобы потом можно было его прочитать.

Это же просто ЛОЛ. Комбайн, который влез уже везде даже в загрузчик, не может мне сказать по-человечески, какой сервис долго завершается ?!

Если бы не авторитарная политика RH, этот шлакd бы почил в бозе, и никто бы о нем уже не вспоминал тащемта.

Потому, что это - логично. Ты знаешь, что такое - логика?

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

Т.е. по вашему выходит, что инициализация системы и ее дальнейшее управление, это одно и тоже?

Конечно.

Давайте тогда понапихаем все это барахло, скажем, в grub2.

Можешь собрать ядро как GRUB2-модуль. И не надо разводить никакой демагогии. Что сказать-то хотел?

Можно еще дальше пойти. И позапихать все в efi.

Я могу вкомпилить initramfs в ядро, а ядро с EFISTUB вкомпилить в прошивку как UEFI executable. Так, в общем-то, вполне делают в очень узкоспециализированных случаях.

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

Хамло.

Может тебе ещё и исходники продукта с прошлой работы притащить?

Неси. Мы тут давно не веселились. Писаки реакта не появлялись тут давно. будет крайне интересно разобрать твою писанину. Я так полагаю, что тыкание носом в субстанцию того кода, который «хрупок» и нежет, как одуванчик, что требует полного функционала systemd - будет весьма пикантен :)

Ты сначала определись, что ты хочешь услышать.

так и быть. Для носящих нимб самоуверенности я поясню еще раз. Назови конкретные, практические задачи, которые требуют реального применения всего функционала systemd. и не образных «сервис1, общается с сервис2 и зависит от глюканиия сервис3», а реальных задач, которые требуют весь фукционал (это не опечатка) кадавра systemd.

И да, видишь ли, ситуация не требует исправления. У меня всё замечательно работает.

ахахаха. замечательно работает. Т.е. ситуация, когда все «хрупкое» у тебя является "замечательной работой? Я даже представить в таком случае боюсь, что в твоем понимании «незначительный инциндент» :) Не иначе как это полный пи-ц, когда пользователи бегут к тебе со сковородками на перевес и начинают бить тебя по нимбу. Тогда, да, конечно, понятно, откуда такая любовь к разжиревшему systemd-кадавру.

Если вычесть Docker-образы, то останется полтора локалхоста. Такая себе популярность.

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

Можешь собрать ядро как GRUB2-модуль. И не надо разводить никакой демагогии. Что сказать-то хотел?

Я могу вкомпилить initramfs в ядро, а ядро с EFISTUB вкомпилить в прошивку как UEFI executable. Так, в общем-то, вполне делают в очень узкоспециализированных случаях.

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

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

Данные слова требуют обоснования

Прибивание udev и login гвоздями к системд это не переусложнение? Те же бинарные логи, для чтения которых нужно изобретать велосипеды? homed и repart это не переусложнение? А systemd-boot? Завязывание GDM на systemd? Одним словом, считается ли попытка запустить щупальца во все компоненты системы переусложнением? В то время, как openrc обладает всеми фишками системд как инита, но не пытается лезть во все и вся и весит 900 килобайт? systemd в чем-то похож на snap. В обеих случаях хорошая идея убивается отсутствием четко определенных целей и, как следствие, убогой реализацией.

Но не тратишь.

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

systemd - лучшее, что случалось с Linux

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

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

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

Прибивание udev и login гвоздями к системд это не переусложнение?

нет, это вендорлок. попробуй загрузить линукс без udev, а кто у нас имеет право на комит?

примеры сломанных юнитов и ссылки на багтрекер - это отсебятина?

Там такой говнокод, что, например, сам Поттеринг не рекомендует использовать Conflicts= в общем случае. В манах про это, конечно же, ни слова.

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

Хорошо, что в этом посте не написали о смене BlackList на DenyList, а то в комментариях только об этом бы и трындели.

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

Не нуждающийся в представлении системный менеджер

Системный менеджер, нужда в котором сомнительна. И это мягко сказано.

Баш это полноценный ЯП, на нем можно что угодно реализовать

Да? Прям таки Тьюринг-полный?

Системный менеджер, нужда в котором сомнительна

В точку.