Релиз systemd 230

Я про это и говорил.

Мне что, переписать всё содержимое initscripts из Debian?

Если ты не видишь другого выхода - то да. И ты точно будешь знать, что у тебя больше нет ошибок и опечаток. Тем более, что два с половиной стартап-скрипта, которые нужны тебе в повседневной жизни, - не так уж сложно переписать для онанимуса, уверенного, что он знает bash/dash/csh/ksh/zsh/rc... 8)

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

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

на systemd потому что он позволяет управлять сиcтемой,

Так, как он умеет. А умеет он пока не очень, как практика показывает. Посмотрим, что принесёт 230. В прошлый раз вот USB-модемы отпали. Казалось бы, при чём тут systemd ? Ан нет, udev-то его часть сейчас.

а не надеяться, что в портянках шелл-скриптов нет глупых опечаток.

Только вот зависимость между шелл-скриптами сильно меньше, чем между компонентами systemd. В основном, страшна поломка только в rc.sysinit, а это очень давно везде написанный компонент. И достаточно простой.

И достаточно простой

гыгы 8) например - вот такой, ну оооочень сложный...

#!/bin/sh

for i in /etc/init.d/S??* ;do

     [ ! -f "$i" ] && continue

     case "$i" in
        *.sh)
             (
              trap - INT QUIT TSTP
              set start
              . $i
             )
             ;;
        *)
             $i start
             ;;
    esac
done

чего отслеживать и чего рестартовать - глючные падающие сервисы чтоли ? мечта говноадминов мля.

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

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

Так админ должен следить, или супер-пупер systemd? Ты уж оперделись. 8)

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

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

Меньше пафоса и оскорблений, глядишь и научишься чему-нибудь.

Так админ должен следить, или супер-пупер systemd? Ты уж оперделись. 8)

Ты уж определись, админ должен сервисы запускать или init? Что за детские передёргивания. Следит админ, для этого у него есть удобный инструмент - systemd. Появится более удобный - возьмут его.

Не тупи, админ должен следить за тем что запущено

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

при чём тут systemd ? Ан нет, udev-то его часть сейчас.

Часть проекта, но не част инита же. В udevе наговнокодить системд не мешает, но и не помогает.

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

Вот только на шелл-скриптах реализовать сокет-активацию или последовательный запуск нескольких веток сервисов зависящих друг от друга получается задачей настолько нетривиальной, что в upstart и openrc его так и не осилили.

В основном, страшна поломка только в rc.sysinit, а это очень давно везде написанный компонент. И достаточно простой.

За последние 2 года не помню ни единственного случая чтобы что-то отваливалось по вине именно init'а systemd. В стабильных репах дистрибутивов точно не было.

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

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

Вобщем, всё понятно. «Эталонное ненужно», глючное, падучее, валящее части системы при каждом новом релизе, поддерживаемое толпой пионэров, уверенных в непогрешимости решения выбранного унылым укурком-мейнтейнером одного из открытых дистрибутивов (шоп лехче було красть гхаз у сусидей) и подхваченного остальными мейнтейнерами по принципу - «делай как он, он же это не зря делает, у него есть план!»...

Лулзов больше не светит, определенность наступила.

Системд отправляется в отстойник на следующие несколько лет, пока не появится в какой-нибудь systembsd под лицензией *bsd, и не будет порезан на независимые части в традициях bsd, а тогда его можно будет бэкпортнуть в линух в виде набора несвязанных между собой сервисов и выпилить ненужное без угрозы для стабильности системы. Пока говорить об этом рано - в его текущем виде эта поделка нужна только пионэрам, чтобы гнуть пальцЫ, какие они супер-пупер одмины.

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

Как я и думал, от поклонников systemd здравого зерна ждать не стоит. У них гента, лось и прочие дистры — ноунеймы, ынтырпрайз говном пользоваться не станет, а значт системд — божественно крут, если указываешь на конкретные проблемы кричат «это дебианопроблемы УМВР». То что влезая в udev поттеринг обещал сохранить поддержку других систем инициализаций, а потом кинул (почему пришлось форкать в eudev). Странный подход к организации разработки, когда решения принимаются по воле левой пятки и разрабочики не считают необходимым тестировать или исправлять написанный ими код... Хотя чего это я, у Вас же всё работает, зачем что-то нагнетать... Искренне надеюсь, что у Вас будет всё хорошо и Вы спокойно доживёте до следующей системы инициализации без подстав со стороны systemd.

Часть проекта, но не част инита же. В udevе наговнокодить
системд не мешает, но и не помогает.

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

За последние 2 года не помню ни единственного случая чтобы
что-то отваливалось по вине именно init'а systemd.

Я тут писал в январе про пойманный race с fsck в 201 на отдельном /usr. Однократно, но, тем не мене, и одного раза было бы достаточно, будь это сервер в необслуживаемом помещении.

За последние 2 года не помню ни единственного случая чтобы что-то отваливалось по вине именно init'а systemd. В стабильных репах дистрибутивов точно не было.

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

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

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

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

Нет, просто указывают на то что те дистрибутивы для которых важна машстабируемость установок и удобное администрирование - переходят на systemd и на это есть объективные причины. Просто изначально аппелировать к «смотрите, есть дистрибутивы без systemd, значит он не нужен» было странно. Есть дистрибутивы без «glibc», есть без Xorg, есть без пакетных менеджеров, но если их востребованность крайне низкая - то это скорее указывает, что «преимущество» это крайне сомнительное и не настолько весомое.

если указываешь на конкретные проблемы кричат «это дебианопроблемы УМВР»

Но ведь действительно, проблема в кривонаписанном юните Network-manager'а в дебиане, в том что он ждёт подъёма сетки по таймауту. В других дистрах это пофиксили, дебиан всё ещё телится.

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

Тем не менее реальной зависимости так и нет. О ней говорили когда udev планировал перейти на использование kdbus вместо сокета, но это так и не запилили.

Продолжим дальше. У админа с сервисом на ватчдоге он так и будет на ватчдоге: рестартится же, сойдёт и так.

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

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

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

Я тут писал в январе про пойманный race с fsck в 201 на отдельном /usr. Однократно, но, тем не мене, и одного раза было бы достаточно, будь это сервер в необслуживаемом помещении.

Вот, наконец-то адекватный аргумент. Можно ссылку на тред, если под рукой?

у админа с сервисом без вотчдога всё так и будет валяться

Нет, он будет делать изначально систему без подпорок.

В том-то и соль, что не знаешь кто свалится, когда и почему.

После процесса отладки и тестирования - знаю. А невведённое в эксплуатацию может и полежать, если что.

Можно ссылку на тред, если под рукой?

Проклятый Поттеринг дотянулся. Что будет когда он умрёт? (комментарий)

Нет, он будет делать изначально систему без подпорок.

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

После процесса отладки и тестирования - знаю. А невведённое в эксплуатацию может и полежать, если что.

То есть системы мониторинга не нужны, потому что отладка и тестирование покрывают 100% кейсов в продакшне?

Спасибо.

То есть системы мониторинга не нужны, потому что отладка и
тестирование покрывают 100% кейсов в продакшне?

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

Нет, он будет делать изначально систему без подпорок.

Шутка дня.

Но ведь действительно, проблема в кривонаписанном юните Network-manager'а в дебиане, в том что он ждёт подъёма сетки по таймауту. В других дистрах это пофиксили, дебиан всё ещё телится.

В моей системе (которая на debian) нет networkmanager'а

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

Это понятно.

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

А я, вроде бы, ни в одном сообщении не писал, что systemd не нужен. Я писал, что мне не нравится systemd, я считаю некоторые вещи в этом проекте потенциально опасными. А про дистрибутивы без systemd я упомянул в том ключе, что там очень сложно становится использовать привычные программы, на первый взгляд, не связанные с задачей инициализации системы. Ей богу, если бы, скажем gentoo с systemd и gentoo с openrc отличались бы только системой инициализации, скажем скоростью запуска (не в пользу последнего) или/и функциональными особенностями (опядь-таки не в пользу последнего), то я бы никогда и не подумал ругать systemd. Каждый выбирает то что ему удобнее, то что решает его задачу. Мне нравилось это в мире linux и я не хочу чтобы это менялось.

br+kvm без запуска виртуалок, sysV быстрее был

# systemd-analyze 
Startup finished in 7.131s (kernel) + 1min 16.397s (userspace) = 1min 23.528s
# systemd --version
systemd 210
+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR

от поклонников systemd

Это не ко мне. Я не поклонник systemd, OpenRC или любой другой системы инициализации.

У них гента, лось и прочие дистры — ноунеймы

Ты указал не генту, а какую-то фунту. Или ты всерьёз считаешь, что каждый форумчанин должен от и до изучить весь список дистровотча? Да, ноунеймы. Deal with it, motherfucker.

Но системный ватчдог на _всё_ подряд - это показатель качества системы.

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

DHCP-сервере, встроенном в systemd-networkd

Когда в него встроят все остальное?

Бомбануло.

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

Подушки безопасности в машине - показатель качества машины.

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

Сын, говоришь, у тебя есть? Искренне надеюсь, что он от соседа.

«Ах! Оскорбление является обычной наградой за хорошую работу» (c)Михаил Афанасьевич

Так ты здесь на работе? Сутки через двое пашешь?

Уже 230, а функционал, обеспечивающий запуск фотошопа, так и не добавили.

Так ты здесь на работе? Сутки через двое пашешь?

Попытайся найти у меня еще какое-нибудь слабое место. 8)

Дитё.

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

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

Здесь была ссылка на список дистрибутивов без systemd с указанием от какого дистрибутива произошёл данный.

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

..., а не надеяться, что в портянках шелл-скриптов нет глупых опечаток.

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

Для не поклонника у Вас слишком много желания отстаивать позиции systemd.

Нет, я просто не терплю активную ретроградщину и прочий луддизм.

за что критикуют systemd.

Критикуют всё. Это конкуренция. У всего есть недостатки. Это факт. Но зачем настолько интенсивно критиковать то, что обычному пользователю не мешает - вот в чём вопрос.

Лично я, правда, не всегда был обычным пользователем. Я пилил свои дистры разной степени экспериментальности. В самых маргинальных был свой самопальный инит на баше. Вернее, даже не на баше, а на busybox sh. И mdev вместо udev, кстати. Можно заменить баш на си, но решения о велосипедах вообще принимаются не от хорошей жизни.

Но сейчас я - обычный юзер, который - так уж вышло - везде использует системы, которые - так уж вышло - используют systemd. И моё отношение к этим системам совершенно не изменилось бы, если бы там стоял OpenRC, runit или какой-нибудь BaldDevil (для всяких олегарчей переведу - «ЧёртЛысый»). Видеть, как народонаселение тратит столько сил на восхваление или (в данном случае) наоборот, обгаживание софтины, которая должна быть максимально незаметна для пользователя - это для меня вообще дикость. Это опенсорс, никто никому ничего не должен.

Подушки безопасности в машине - показатель качества машины.

Э, нет. Тут принципиально иной момент. :-)

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

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

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

О! Надо запомнить. Замечательное сравнение.

Судя по тому что Вы пишете, наши взгляды весьма схоже, тем страннее тот факт, что вы не можете меня понять, поставив себя на моё место. Я не пытаюсь обгадить что-либо. Я призываю не забывать за «УМВР» о проблемах, связанных с этим проектом. Представьте, что ситуация ровно обратная, большинство дистрибутивов использует какой-нить инит и ломает совместимости с таким замечательным systemd, который даёт столько возможностей и Вам так нужен, порадует ли Вас это? Пусть это чистая фантазия, но вот вполне возможный расклад, через пару десятков релизов, когда systemd подомнёт под себя половину подсистем gnu\linux, добавят в systemd нечто несовместимое для Вас с дальнейшим его использованием, не знаю может закроют код ключевых компонентов или ещё что-то придумают. Что делать, куда бежать? Ведь взять и выдрать будет уже не так просто. Можете считать меня параноиком, но исключать такую возможность нельзя.

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

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

Представьте, что ситуация ровно обратная, большинство дистрибутивов использует какой-нить инит и ломает совместимости с таким замечательным systemd, который даёт столько возможностей и Вам так нужен, порадует ли Вас это?

Это происходит не в первый раз и не в последний. Как только кто-то запилит что-то лучше - дистрибутивы перейдут на это, как перешли с upstart на systemd, а до этого с sysv на upstart.

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

Тогда последнюю открытую версию форкнут и будут пилить. Наличие закрытых компонент будет достаточным аргументов для активной разработки альтернативы.

Что делать, куда бежать? Ведь взять и выдрать будет уже не так просто.

А что будет если RedHat закроет свои наработки? Или запретит распространять запиленный ими софт? Будет то же самое - на основе последней открытой версии будет пилиться альтернатива. Или просто активные разработчики перейдут на другие, альтернативные проекты чтобы заменить зашкварившийся. Так появились Xorg, Gnome и остальные.

Представьте, что ситуация ровно обратная, большинство дистрибутивов использует какой-нить инит и ломает совместимости с таким замечательным systemd, который даёт столько возможностей и Вам так нужен

Мой род деятельности - так уж вышло - совершенно не завязан на систему инициализации.

gnu\linux

А вот за такое написание можно и КЛБ.

может закроют код ключевых компонентов

Не впервой. Обычно в таком случае появляются форки последних опенсорсных версий.

Можете считать меня параноиком

Уже.

Не наблюдаю.

Если это сервер в проде — естественно не годятся. Для локалхостных серверов мамкиных хакиров годится что угодно, лишь бы клей не нюхал.

Не наблюдаю.

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

Эти срачи до сих пор живы? Жееесть!

Блин, по факту systemd уже «победил» ибо на него перешли все основные дистрибутивы. Да, не спросив мнения админов локалхоста.

Что же касается самого системд, мне он нравится. Банально за фичи типа:
loginctl seat-status, loginctl session-status и за loginctl attach seat1 $девайсина

Мультисит из коробки! Круто-же!

Ну где еще такая красота есть? Осталось иксы допилить для singleXorg multiseat и будет вообще волшебство.

Ну и для тех, кто говорит что оно жирное:

$ldd /sbin/init
	linux-vdso.so.1 =>  (0x00007ffc0f14a000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6efc114000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f6efbf0e000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6efbd05000)
	libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f6efbac7000)
	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f6efb8b9000)
	libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f6efb691000)
	libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f6efb47a000)
	libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f6efb26a000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f6efb022000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6efae05000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6efaa3c000)
	/lib64/ld-linux-x86-64.so.2 (0x00005568a0e97000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6efa7cb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6efa5c7000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f6efa385000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6efa180000)
$ systemd --version
systemd 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN
$ systemd-analyze 
Startup finished in 8.490s (firmware) + 10.826s (loader) + 2.447s (kernel) + 5.917s (userspace) = 27.681s
$ systemd-analyze blame 
         12.469s apt-daily.service
          3.276s networking.service
           894ms systemd-fsck@dev-disk-by\x2duuid-8B8B\x2d2FAA.service
           552ms Share-Sound.mount
           351ms Storage.mount
           265ms dev-sdb1.device
           243ms Share-Video.mount
           211ms ModemManager.service
           203ms Share-Anime.mount
           190ms accounts-daemon.service
           174ms Share-share.mount
           158ms systemd-logind.service
           157ms thermald.service
           157ms grub-common.service
           156ms apparmor.service
           129ms pppd-dns.service
           128ms rsyslog.service
           126ms alsa-restore.service
           125ms gpu-manager.service
           125ms lm-sensors.service
           122ms systemd-hostnamed.service