systemd: преимущества и недостатки для экосистемы Linux.

alright> Мастер, как вам удается писать ваши программы сразу без ошибок?

А зачем забагованное Г тащить в продакшн?

alright> Уже сейчас почти во всех дистрибутивах вместо тонн разной лапши — одна система инициализации, по которой можно писать документацию и обучать людей.

Так и раньше было - sysvinit.

А зачем забагованное Г тащить в продакшн?

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

Прошу прощения, но разве обязательно для того, что бы понять, что тебе неприятно дерьмо на крыльце, быть экспертом в области экскрементов?

P.S. К systemd имею нейтральное отношение, это было общее утверждение не выражающее мое отношение к systemd.

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

ништяков

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

Если нужно чтение тонны манов без получения существенных преимуществ - значит новая система ненужное говнище.

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

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

Так и раньше было - sysvinit.

Не было так. Был sysvinit, был upstart, был openrc. Уже 3 системы учить, а станет возможно ограничиться одной.

systemd: преимущества и недостатки для экосистемы Linux.

Это не холивар и не флейм.

Это деление на ноль.

И кто такая эта ваша экосистема?

sysvinit

System V init — общее (родовое) название для кучи немного похожих в настройке и управлении инитов, каждый со своими особенностями.

Т. ч. ты здесь (как всегда) не прав.

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

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

без получения существенных преимуществ

Для меня преимущества стали очевидны, естественно, после прочтения тонны манов.

В чём конкретно преимушества для меня:

• Не нужно городить костыли на баше — использую простенький шаблон для юнитов, хотя, в последнее время не возникает необходимости — мейнтейнеры обеспечивают;
• Не нужно городить километровые пайпы для чтения нужной информации из логов — для всего есть человекопонятные опции;
• Автоматический рестарт юнитов при падении — не нужно плясать с бубном вокруг ряда сервисов, если выпал один промежуточный;
• Простая и понятная настройка всего — несколько конфигов (а не тонны, раскиданные по всей системе, как было в легаси) с парами ключ=значение;
• Хорошая документированность (я не говорю, что легаси-набор плохо документирован, я лишь говорю, что systemd не уступает);
• И многое, многое другое...

Ага, замечательный пример. Беспристрастный. Давай возьмем что-нибудь и сравним это с говном на своем крыльце. Это будет как нельзя лучше доказывать нейтральность моей точки зрения.

Это не холивар и не флейм.

Дооо. «Это не троллинг, мне правда хочется разобраться»

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

А почему этот пример вообще как-то относится к ситуации с инитами и пригоден для того, чтобы её описать?

Просто потому что с этим так ии иначе сталкивается каждый. Сталкивается вне зависимости от подкованности в вопросе. Только об этом я и говорил. Это был ответ на конкретное утверждение, тоже слабо, на самом деле, связанное с инитами.

Ты привел плохой пример, который не говорит ни о чем кроме того что ты — типичный ненавистник системд, который считает его дерьмом просто потому что это модно. И никакая твоя демагогия никого уже тут ни в чем не убедит. Меня во всяком случае — точно не убедит.

Чего на него ополчилось столько непростых, заслуженных людей?

По-моему, ополчились только горстка ЛОР'овцев, а люди, которые определяют путь развития дистрибутивов, активно этот systemd продвигают. Может не так страшен чёрт, как его малюют?

С другой стороны, известны случаи, когда крайне ущербные и неудачные программные продукты получали большую известность и распространение. Классический пример этому — Git.

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

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

Я правда отношусь к systemd нейтрально, к ЛП — настороженно.

Но что ж. «Ваше мнение очень важно для нас».

Я просто хочу узнать: systemd - это хорошо или плохо? Был бы я сопляк, как двое из начала треда, я бы сутками мониторил ЛОР. Но я занятой человек.

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

Да, кстати, если тебе интересно, изменения назрели уже давно. Время требует перемен и в Solaris и Mac OS X свой аналог systemd сделали лет 10 назад.

Надо в ЛОРе ввести новую функциональность: запирать темы с тегом systemd на quiz-замок.

thumb up!)

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

в общем я согласен со всеми доводами, кроме: километры пайпов нужны для гибкости. она ими и обеспечивается. Предожите мне вариант journalctl без пайпов, аналогичный

cat /var/log/messages| awk '{ print $5 }'

Теперь о моем опыте с systemd. На CentOS 7 для проверки фс systemd вызывает fsck.xfs, фиктивный бинарь. Он фс не чекает. Поэтому когда xfs попортилась, я оказался с незагружаемой системой. Это раз. Во-вторых, я не мог легко, как в случае с «костылями на баше» исправить ситуацию, т.к. fsck.xfs вызывался в бинарнике.

Предожите мне вариант journalctl без пайпов

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

фиктивный бинарь

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

Я не говорил, что systemd идеален, но он проще.

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

)И да, в init я могу не особо вдаваясь в маны сделать так,что в первой консоли у меня htop,а в остальных залогиненный под рутом bash (это домашнии компьютер,да и на работе трояны ко мне запускать не станут)
А вот как это сделать в systemd?
Ну опираясь на неполное искоренение старой архитектуры в виде /etc/passwd и /etc/shels я смог этого добиться через создание дубликатов рута с именами вида root_tty1 и .т.д. по номеру.
Но это благодаря прежней системе инициализации.
А вот как мне,простому пользователю сделать средствами именно системды?
Я задал вопрос intelfx,но он молчит.

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

Ответил на вопрос в том треде.

Я считаю, что некорректно говорить «в init я могу не особо вдаваясь в маны сделать так, что <...>». Вряд ли каждый человек с рождения знает синтаксис /etc/inittab.

Про /dev/ttyN и inittab собственно мне расказал знакомый,ну а cообразить,как строку вида
6:12345:respawn:/sbin/getty 38400 tty6
переделать сначала
4:123456:respawn:/bin/bash
и только напоровшесь на некорректное поведение mc и вешания всего на одну консоль и чтения мануальника к getty строка приходит к конечному виду
1:123456:respawn:/sbin/getty --skip-login --login-program /usr/bin/mc 38400 tty1
Ну да смысл этих двух опции ясен из названия.

О чём и речь. Исходно никто не знает ни про то, ни про другое. Следовательно, говорить «systemd сложен, потому что про него я не знаю, а про обычный инит знаю» некорректно.

Так это берётся через простое сопоставление,при стандартном конфиге mc/bash работает корректно,а при таком прямом запуске нет.
Ну а из факта возможности выбрать шелл ясно что он должен как то выбираться.
Ну и что делает опция --login-program вопросов не вызывает.

Мы говорим сейчас не о параметрах, передаваемых getty. Они при переходе к systemd не изменились вообще никак. Если посмотреть в юнит-файл /usr/lib/systemd/system/getty@.service, то можно увидеть, что там есть строка ExecStart=-/sbin/agetty <...>.

Мы говорим о том, где эти параметры указывать. Так вот, я утверждаю, что файл /etc/inittab настолько же неочевиден, как и /usr/lib/systemd/system/getty@.service.

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

Вероятно, вы путаете getty и инит (systemd/sysvinit). Это разные вещи. Ещё раз повторяю, что при переходе к systemd первое не изменилось никак, и getty по-прежнему принимает все эти параметры. Изменилось то место, куда их нужно вписывать. Оно не имеет к getty никакого отношения.

Поменять то эту строку сразу для всех консолей у меня получилось.
Но вот сделать индивидуальную настройку для каждой консоли отдельно для меня уже проблема.
Конечно,я как опытный пользователь Linux могу предположить то,что @ в названии есть индентификатор для замены по шаблону.
Ну и с концепцией выбора конфига по симлинку знаком.
Ну и назначение файлов passwd и shels мне известны
Но всё это знания и опыт,которые для умения настройки inittab совсем не нужны.
А вот для настройки systemd обязательны.
Вот так.

П.С. Конечно я читал ман по inittab,но в основном как шпаргалку по синтаксису (да я и сейчас англииского не знаю,так себе решаю геометрические ребусы с отдельными известными словами)

Зато для умения настройки inittab нужно знать синтаксис inittab. Да, он простой — настолько простой, что его можно понять интуитивно. И ввиду этого гораздо менее гибкий, чем концепция юнитов в systemd.

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

Что касается задания параметров для одной из консолей: @ в названии юнита — это указание на то, что файл юнита является шаблоном. Например: если запустить юнит getty@tty1.service, то сначала будет произведена попытка запустить именно этот юнит, но если его не существует, то будет взят файл-шаблон getty@.service и в него вместо %I будет подставлено tty1.

Поэтому, чтобы изменить параметры getty для одной конкретной консоли, нужно взять файл getty@.service, скопировать под именем getty@tty1.service и внести в него требуемые изменения.

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

alright> Потому что так работает оупенсоурс: выкатывают забагованное говно, а потом всем миром его тестят и фиксит.

Не путай федору и убунту с опенсорсом.

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

Выдавать гибкость за костыли - это мода такая фанбоев Поцеринга? То есть, что не монолит то костыль?

Loki13> Думаю старые подходы и старое устройство ты тоже не с молоком матери впитал, а долго и нужно учил.

Не имеет значения. Более того - старое устройство я очень быстро выучил. По нему просто не нужно читать тоны манов - достаточно центнер.

Loki13> Плохо старым одминам, что нужно учить новое, а вот тем кто только сейчас приходит в линукс

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

Loki13> и возможно systemd будет даже проще, т.к. не надо будет знать свой подход для разных дистрибутивов, а выучил как оно в системд и можешь любой сервер одминить. Это же хорошо.

Это попытка свести разные дистрибутивы к одному, которая подразумевает потерю смысла в разных дистрибутивах и переход на модель монополии RedHat. Да - systemd это не стандарт, а монополия.

Loki13> Был sysvinit, был upstart, был openrc. Уже 3 системы учить

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

intelfx> Т. ч. ты здесь (как всегда) не прав.

Нет - как раз именно я тут абсолютно прав. А такие как ты начинают демагогировать на тему «а ведь иниты ведь разные - всё равно каждый надо долго изучать, даже если они называются system v». Почему никто не ныл о «проблеме» разных инитов раньше, а также никто даже не думал о том, чтобы изменить ситуацию? Правильно - потому, что кардинальных различий не было, а все различия сводились к разнице между дистрибутивами.

r3lgar> Не нужно городить костыли на баше — использую простенький шаблон для юнитов

В том же Debian на sysv-rc тоже ничего городить не надо - есть готовый шаблон.

r3lgar> Не нужно городить километровые пайпы для чтения нужной информации из логов — для всего есть человекопонятные опции;

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

r3lgar> Автоматический рестарт юнитов при падении — не нужно плясать с бубном вокруг ряда сервисов, если выпал один промежуточный;

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

r3lgar> Простая и понятная настройка всего — несколько конфигов (а не тонны, раскиданные по всей системе, как было в легаси) с парами ключ=значение;

systemd не может обеспечить настройку всего и вся - факт.

r3lgar> Хорошая документированность (я не говорю, что легаси-набор плохо документирован, я лишь говорю, что systemd не уступает);

Нет - ты завёл речь о преимуществах. Значит ты утверждаешь, что «легаси» (которое на самом деле не легаси, а актуальщина) плохо документировано.

r3lgar> И многое, многое другое...

Аналогично.

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

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

Благодаря systemd уже не должно быть наплевать: systemd + dualboot/offtopic8.1

Небось кукаретики systemd начнут сейчас орать и брызгать слюнями: «А нефиг дуалбут держать!». Что самое интересное, такие эпичный фейлы появились впервые в истории инитов и именно на systemd. Это говорит о том, что systemd сам по себе проблемен и от таких проблем не избавится ещё очень долго (напомнить, сколько его уже разрабатывают?).

Как ты будешь вычленять из общего лога строки отдельного демона?

Супервизор — отдельный демон, и он тоже может упасть. systemd тоже может упасть, но он сам встанет, отряхнётся и попрёт дальше.

systemd обеспечивает настройку того, что контролирует, а так как он PID 1, нутыпонил.

Ладно, как я из мана openrc узнаю о существовании мана по, например, rsyslogd?

Вывод: существенных преимуществ у systemd нет

Ты делаешь выводы со слов какого-то упоротого гентушника. Прежде чем делать выводы, ознакомься сам. А судя по портянке, которую ты понаписал, ты systemd в глаза не видел.

Был бы я сопляк,

был бы ты не сопляк - давно бы прочитал документацию и всё понял сам.

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

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

Небось кукаретики systemd начнут сейчас орать и брызгать слюнями: «А нефиг дуалбут держать!».

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

Небось кукаретики systemd начнут сейчас орать и брызгать слюнями: «А нефиг дуалбут держать!»
Что самое интересное, такие эпичный фейлы появились впервые в истории инитов и именно на systemd. Это говорит о том, что systemd сам по себе проблемен и от таких проблем не избавится ещё очень долго (напомнить, сколько его уже разрабатывают?).

Это проблема не systemd, а ниасиливших документацию, в солярисе тоже такое поведение по умолчанию, но никто не мешает тебе использовать nofail или noauto.
@тред не читай, сразу отвечай

#против_systemd
Посмотри в этот скрипт,там в начале должны быть строки вида
progname_path=path/progname

ИМХО если этого нет,то это повод усомниться в профессионализме разработчика.

И если сервис простой,то можно переписать rc скрипт от другого сервиса.
А если rc скрипт не тривиален и сложен,то скорее всего systemd будет пускать туже самую Debian only портянку.
И дополнительно к bash/perl/python тебе придётся учить ещё и доки к systemd

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

Например, для вебсерверов это очень частый юзкейс. Вам нужны все айпишники с 403. Или вам нужны айпишники, где время ответа больше ... Или ... Я бы сказал, что лог без парсинга - это исключение. Особенно на нагруженных машинах. Так что лично одна из причин, почему я люблю Linux/Unix - это как раз текстовые файлы и горы вот этих пайпов.

Который является симлинком на нормальный бинарь

Я просто для ясности здесь уточню, что

...fsck.xfs simply exits with a zero exit status.
If  you  wish  to  check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).

Я не говорил, что systemd идеален, но он проще.

Хотелось бы в это верить.) Я пока еще не освоился с кульбитами типа:

mv /etc/systemd/system/multi-user.target.wants/openvpn@.service /etc/systemd/system/multi-user.target.wants/openvpn@ninja.service

Quasar, ты вот много пишешь против systemd. А есть у тебя конкретные юзкейсы? Или ты просто так против, чисто теоретически? Мне вот очень нравится идея классического UNIX (70-80), System V init и мои скрипты для запуска сервисов на баше, но сейчас не 80ые... типа есть требования по хотплагу, по зависмостям сервисов и т.д. Как ты предлагаешь обеспечивать зависимости запуска?

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

Вот ты это откуда взял? Ты какую-то книгу по архитектуре ОС прочитал или что вобще? Или это UNIX-way в твоем понимании? Это как раз _должно_ быть в системе запуска.

Вот тебе не нравится, что systemd навязывает RedHat со своей монополией. Ты не признаешь Ubuntu и Fedora. Да ты BSDешник в чистом виде!:) Они до сих пор живут с технологическим отставанием в 10 лет, потому что либо «это не надо», либо нет ресурсов, чтобы сделать. Ты можешь отправиться в их лагерь, но когда придешь устраиваться на работу, выясниться, что BSD нафиг никому (бизнесу) не сдалась. Вот будешь им доказывать на собеседовании, что они не правы, что это все ненужно.

Кто до RedHat предожил init систему, которая бы всех и вся устраивала? Да никто! Был upstart. Я ковырялся в upstart и честно сказать, больше не хочу. Имхо, Г****. openrc? ну классно-классно, все сразу схватились. Время большого количества дистров с разными пакетными манагерами и прочим уже прошло. Линукс стал сложным проектом, его сейчас могут двигать только компании с финансами.