Запретить systemd на форуме

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

А вы знаете хоть одного человека, который использует телефон без СИМ-карты? Что? Один-два? Из нескольких тысяч? Стало быть, СИМ-карта - неотъемлемая часть телефона! Все на борьбу с мобильным рабством! Даёшь освобождение телефонов от СИМ-карт! Срочно создать opensource-телефон без слота для СИМ!

телефон без слота для СИМ

В процессе…

eSIM в Билайне в DC (комментарий)

Кому нужны?

Ты о чём?

О вбросе.

О каком?

Раз уж абсолютное большинство запрещает считать systemd классной штукой, то не пора ли прописать это в правилах? В оффтоп-лист, например. Дескать, любое упоминание systemd в положительном ключе приравнивается к оффтопу или вообще запрещено и наказуемо.

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

Из-за несовершенства движка нельзя прикрепить к посту опрос. Но если бы было можно, то он был бы таким: «Согласны ли вы?» с вариантами ответов «Да» и «Нет».

об этом

Как Гура может кому то не нравиться? Это физически невозможно.

Стало быть, СИМ-карта - неотъемлемая часть телефона!

0. Смартфоны могут быть с самой разной аппаратной и програмной частью.
1. Симкарта часть не столько телефона, сколько операторской сети и оператору действительно всё равно, через какое устройство ты к нему подключаешся.
2. Смартфон можно подключить по WiFi
3. Смартфон можно вообще не выводить в сеть и использовать только как локальное устройство.

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

Это уже интереснее

А вы знаете хоть одного человека, который использует ПеКа без браузера? Что? Один-два? Из нескольких тысяч?

Может и браузер неудаляемым сделать?

Стране

очень инфантильно, согласен

Лучше снять по одной звезде всем, кто без аватарки бородоликого, так правильней. Нет аватарки - не признаешь геноцид спо, ну за Free Software Matter 🤘, не чокаясь.

Может и браузер неудаляемым сделать?

Он в винде и так неудаляемый

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

Тем, что когда найдут баг в другом приложении, его поправят, после чего обновят приложение. Когда баг поправят в systemd-resolved, с увеличением версии пакета пересобрать и переустановить надо будет всё. Включая, внимание, init.

в каком дистрибутиве системда разбита на эти отдельные «небольшие приложения»? Или внезапно нет таких?

Есть. ALT Linux например. Только в случае необходимости обновления одного подпакета, так как сборка из общего исходника, всякие dist-upgrade потянут всё остальное, что из этого набора установлено. Так что ворох отдельных подпакетов не меняет ничего.

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

Язабан.

P.S. systemd не пользуюсь (так уж сложилось), но что в нём плохого, не понимаю.

Gentoo. Форкнули systemd и отделили от него eudev с elogind

Проблема в этом форке в том, что ABI у systemd меняется, как вода в унитазе (кредо у них такое: что-то там такое с never). И успеть за их изменениями сложно. В итоге eudev с elogind использовать можно, но только если в репозитории нет ещё и systemd, так как совместимость регулярно разламывается:

https://lists.altlinux.org/pipermail/devel/2019-November/208963.html и далее по ветке.

Конечно, можно не торопиться обновлять systemd, как вариант, но это тоже может быть чревато.

Что ты называешь systemd? systemd, который менеджер системы, - не комбайн.

И даже он - комбайн. ldd покажет. :-)

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

Нет, именно это ужасно, и за это надо отрывать руки.

Что заботливо упаковывать все компоненты systemd по отдельности банально никому не всралось?

Всралось, упаковано. Но почти бесполезно. Но ты не поймёшь. :-)

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

А я поймал не один. И достаточно фатальные. И это при том, что я его практически не использую. Так, чисто посмотреть.

Нет, именно это ужасно, и за это надо отрывать руки.

Вообще, если бы репозиторий разделили и сами компоненты systemd разделили, может было бы и лучше.

И какие?

И даже он - комбайн. ldd покажет. :-)

Это ни о чём не говорит.

Но ты не поймёшь

А ты уверен, что это именно я не пойму, а не ты не объяснишь?

Это ни о чём не говорит.

Это говорит от том, что лишнего использует init. И часть проблем от того, что зачем-то это лишнее используется.

И какие?

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

А ты уверен, что это именно я не пойму, а не ты не объяснишь?

Я тебе уже раза 3 или 4 пытался объяснить ущербность стиля «всё в одном тарболе» для сборки и сопровождения пакетов. Вот прямо в этом обсуждении, правда в ответе не тебе, про необходимость пересобрать/переустановить всё: Запретить systemd на форуме (комментарий)

Это говорит от том, что лишнего использует init. И часть проблем от того, что зачем-то это лишнее используется.

systemd - не [только] инит. Каких проблем? Что именно ты считаешь лишним?

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

Во первых, почему это? Если он уже выполняется, то ему не нужно грузить новые библиотеки, даже если они обновились. Ну и если даже нужно, в чём критичность, sudo systemctl daemon-reexec набрать сложно? Что такое «рейс»?

systemd - не [только] инит. Каких проблем? Что именно ты считаешь лишним?

Всё, что не нужно для старта системы. Чем меньше код init, тем меньше вероятность ошибок в главном процессе ОС.

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

Увы, но в библиотеках могут закрываться CVE например.

sudo systemctl daemon-reexec

Иногда systemd считает, что надо перезагрузить ОС.

Что такое «рейс»?

https://ru.wikipedia.org/wiki/Состояние_гонки

Всё, что не нужно для старта системы. Чем меньше код init, тем меньше вероятность ошибок в главном процессе ОС.

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

Увы, но в библиотеках могут закрываться CVE например.

Окей, это причина.

Иногда systemd считает, что надо перезагрузить ОС.

И как он это аргументирует? И может быть он прав?

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5_%D0%B3%D0%BE%D0%BD%D0%BA%D0%B8

А. Впервые вижу что бы кто-то сокращал «race condition» до «рейс». Да, окей, могу поверить что ты на что-то такое наткнулся. Что бы этого избежать, нужно добавить x-systemd.before= и/или x-systemd.after= в /etc/fstab. Это может быть не совсем очевидно, но зато весьма удобно, если приходится иметь дело со вложенными разделами/luks/zfs/etc.

И как он это аргументирует?

Да никак особо. «systemd[1]: Reloading.», и система идёт в перезагрузку следом.

И может быть он прав?

Может. Но нафига такая автоматика?

Это может быть не совсем очевидно, но зато весьма удобно, если приходится иметь дело со вложенными разделами

Всего лишь необработанный fstab, в котором есть отдельный /usr (ага, «нам не нужен отдельный /usr», знаю, знаю). И попытки что-то начать запускать до того, как /usr смонтирован.

Да никак особо. «systemd[1]: Reloading.», и система идёт в перезагрузку следом.

Вот так, на ровном месте? Должна быть причина.

Может. Но нафига такая автоматика?

Без знания причины на этот вопрос не ответить.

Всего лишь необработанный fstab, в котором есть отдельный /usr (ага, «нам не нужен отдельный /usr», знаю, знаю). И попытки что-то начать запускать до того, как /usr смонтирован.

Вообще да, не нужен. Не вижу ни одной причины его отделять. Можно ещё пожаловаться, что с /etc на отдельном разделе ничего не монтируется. Впрочем, это уже давно исправили, насколько мне известно.

Вот так, на ровном месте? Должна быть причина.
Без знания причины на этот вопрос не ответить.

Причина есть - обновление ОС.

Вообще да, не нужен. Не вижу ни одной причины его отделять.

Кто видит, кто нет. Но это не важно. Кем надо быть, чтобы начать запускать приложения до окончания обработки fstab?

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

Детские косяки оптимизма не добавляют. Как и перетягивание одеяла на себя.

Причина есть - обновление ОС.

И почему я сейчас сижу на Arch и этого не происходит? И почему этого не происходило на Gentoo и Debian, которыми я пользовался до этого? Это может быть проблемой не systemd, а например мэйнтейнеров, которые добавили хук уводящий систему в ребут и systemd здесь делает что сказали - ни больше, ни меньше. Поэтому я и спрашиваю.

Кто видит, кто нет. Но это не важно. Кем надо быть, чтобы начать запускать приложения до окончания обработки fstab?

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

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

Детские косяки оптимизма не добавляют. Как и перетягивание одеяла на себя.

Детский косяк - это к вашим альтернативам, которые не умеют, например, в scope и творят всякую дичь. Например: когда падает сессия пользователя и дочерние процессы теряют родителя, их родителем становится init. Очень умное решение, да? А потом когда перезапускаешь сессию, то что-то не грузится, что-то не работает и хрен пойми, почему. А всё потому что процесс, который должен был вместе с сессией помереть, например, держит какой-то lock.

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

Нет, ну я не проверял конечно, но на вменяемость как-то так надеюсь. :-)

Если systemd делает что-то не так как ты привык, это ещё не значит что это - плохо.

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

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

Зачем? Есть fstab. Изволь сделать всё, что там написано, а уже потом развлекайся.

А всё потому что процесс, который должен был вместе с сессией помереть

Точно! Особенно screen. Ну и тому подобное. :-)

Нет, ну я не проверял конечно, но на вменяемость как-то так надеюсь. :-)

Ну и вот. А винишь systemd. Единственная ситуация, когда оно действительно перезагрузит систему вопреки твоему желанию - в случае краша, или если ты в него кинешь SIGKILL. Но, ИМХО, это единственное что имеет смысл сделать, если подох init, не важно systemd это или нет.

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

Нет, не значит. Общепринятые подходы способны менятся, если новые из них чем-то лучше старых. К тому же, /etc/fstab не выкинули на мороз, хотя и могли. Так что systemd всё же придерживается старых подходов, хотя и не следуют им в точности. Примонтированный /usr скорее всего является необходимостью для того что бы следовать FHS. Например, в /usr лежат генераторы, которые конвертируют /etc/fstab в unit-файлы, а так же unit-файлы базовой поставки systemd, unit-файлы предоставляемые пакетами. Ключевая особенность - обновлениям системы разрешено удалять или менять эти файлы без боязни поломать то, что руками сконфигурировал администратор. В /etc же лежат именно модификации (Drop-in) этих файлов, либо полные их копии, если администратор решил, что так нужно - что обновления этих файлов в /usr должны быть полностью или частично проигнорированы.

В случае с предшественниками, пардон если не прав, всё было в кучу и скрипты лежали в /etc/init.d. Где им не место, потому что /etc - как раз для всего, что администратору допустимо ломать руками как вздумается, и что следовало бы игнорировать при обновлении.

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

Зачем? Есть fstab. Изволь сделать всё, что там написано, а уже потом развлекайся.

Затем что теперь это - общепринятый подход :D

И хотя это стёб, но не без доли истины.

И да, что касается /usr, я уже написал выше. С другими точками монтирования проблем не возникает, насколько мне известно, и указывать что-то дополнительно не приходилось. Но ты можешь и сам придумать ситуацию, где монтирование всего разом - не [самый лучший] вариант. Или когда отвалившееся (Например - сетевое), нужно примонтировать обратно, когда появится такая возможность (Например - восстановится соединение). И пока оно не примонтировалось обратно, хорошо бы было что бы сервис, которому этот маунтпоинт нужен, был остановлен, а затем - перезапустился. Окей, это может быть не нужно, если всё что ты держишь - файлопомойка под диваном или десктоп, но это ни коим образом не значит, что это не нужно вообще никому.

Точно! Особенно screen. Ну и тому подобное. :-)

Ну толсто же! Если твоя сессия померла, но в ней остались процессы, то scope с этими процессами никуда не денется (Если в конфиге logind ты явно не указал, что такие scope нужно убивать). При этом ты в любом случае будешь знать, что «вот эти процессы остались от вот этой сессии» и получишь возможность их разом прибить, если захочешь.

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

Про /usr есть ещё такая аргументация https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ .

У меня есть аватарка

Гура

Это название сыра?

Нет, имя персонажа на аватарке torvn77

Странно, что у него на аватарке не таракан

Ну и вот. А винишь systemd.

Так есть основания.

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

Ты думаешь, или ты точно знаешь? :-)

Общепринятые подходы способны менятся, если новые из них чем-то лучше старых.

Но старые остаются.

К тому же, /etc/fstab не выкинули на мороз, хотя и могли.

Так в той ситуации считай, что выкинули. Потом вернули, но не знаю, силами мантейнера, или в основной ветке.

Или когда отвалившееся (Например - сетевое), нужно примонтировать обратно, когда появится такая возможность (Например - восстановится соединение)

Это нужная штука, но вот место ли етой штуке в init? Однозначно нет. Как не место и засунутой туда замене xinetd.

Ну толсто же!

Почему толсто? Типовой рабочий (т.е. нерабочий :-) ) случай. Многие нарвались.

Так есть основания.

«Я увидел что оно перезагружает систему» - не основание.

Ты думаешь, или ты точно знаешь? :-)

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

Но старые остаются.

Это не совсем так. И к тому же они остались - в старых системах, где им и место.

Так в той ситуации считай, что выкинули. Потом вернули, но не знаю, силами мантейнера, или в основной ветке.

Ты же прочитал ссылку что я скинул? Прочитай. Если мы про /usr до сих пор. Там пишут что отделяемость /usr была ошибкой, systemd у тебя или нет - не важно.

Это нужная штука, но вот место ли етой штуке в init? Однозначно нет. Как не место и засунутой туда замене xinetd.

Тебе ещё раз повторить что systemd - это не [только] init? Коротко - однозначно да, место. Незачем плодить лишние сущности. И не нужно думать о systemd как о init, оно решает другую единственную задачу - менеджмент сервисов и их зависимостей.

Почему толсто? Типовой рабочий (т.е. нерабочий :-) ) случай. Многие нарвались.

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

Был у меня когда-то такой телефон. Sony Ericsson t608.

и ещё одна исключительная, когда systemd упал.

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

Ты же прочитал ссылку что я скинул? Прочитай. Если мы про /usr до сих пор. Там пишут что отделяемость /usr была ошибкой

несколько десятков лет не было ошибкой, а потом вылезло эдакое юное дарование, и всё стало ошибкой.

Тебе ещё раз повторить что systemd - это не [только] init?

О, так и говорю - комбайн. Консенсус наступил. :-)

Коротко - однозначно да, место.

Нет, в init - не место. Но systemd - это комбайн, потому там - место. И потому падать он будет ещё не раз.

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

Если его отключают, зачем он вообще нужен?

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

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

несколько десятков лет не было ошибкой, а потом вылезло эдакое юное дарование, и всё стало ошибкой.

Либо было, но ты об этом не знал. Текст по ссылке ты так и не стал читать, как я понял. Окей, держи главное:

Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* -- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases. 

И судя по дате выхода Fedora 15, это на 2011-ый год и списочек винрарен. На всякий случай напомню, что systemd «поглотил» udev на несколько лет позже.

О, так и говорю - комбайн. Консенсус наступил. :-)

С какой стороны посмотреть. С моей - ваши иниты старого поколения и компания - дефективный недоинструмент для менеджмента сервисов и их зависимостей. А systemd - адекватный.

Нет, в init - не место. Но systemd - это комбайн, потому там - место. И потому падать он будет ещё не раз.

Значит хорошо что systemd - не [только] init. Прохладно сказание про падения, но что-то с действительностью оно не пересекается. Ну и он хотя бы поддерживается. И хорошо что не пытается удовлетворить необоснованное желание каждого первого выстрелить себе в ногу.

Если его отключают, зачем он вообще нужен?

Зачем убивать процессы сессии? Что бы освободить локи, что бы освободить ресурсы, что бы случайно не оставить висящими процессы, которые могут, например, давать сетевой доступ, etc. Отключают его именно из-за таких людей как ты, которые не читают маны и орут СЕДЛАЙТЕКАКЯПРИВЫК!!1. Для остальных есть systemd-run ... который позволяет запустить приложение/сервис так, что бы он не был частью сесии и при её завершении продолжил работу. Стоит отметить, что это не замена screen, а дополнение.

- systemd падает!

- *your_init* тоже падает!

- Это другое!

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

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

А если произошло - почему это проблема systemd, а не мэйнтейнеров, которые выкатили кривое обновление?

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

Окей, держи главное:

И что? ой-ой, у меня пульса сломалась, когда опа системная. NetworkManager, ModemManager - это вообще приложения, без которых повеситься можно, да? :-)

You don't believe us?

Верим, верим. Хипстеры неноделанные. :-)

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

Да. Он сам стреляет в ногу регулярно. Кстати, эта поделка мне однажды DoS устроила. Ага, потому, что inetd недоделанный. Клиент захотел контейнер с CentOS ну и вывесил поделие без файрвола. Поток в гигабит (больше просто нельзя было) исходящего не хочешь?

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

Я, как бы, сам в состоянии решить, что надо тормознуть.

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