Вот это и плохо,так как приведёт к перекосу в пользу тех кто платит.
И собственно кто такой RedHat чтобы мочь проташить systemd?
Да ни кто,нет у них такого авторитета.
Но у RedHat есть пользователи серверов,на которых будут ориентироваться разработчики этих серверов и вот у же у значительной части сообщества проблемы.
И чем больше такая зависимость,тем больше всякие протаскиватели будут наглеть.
Ну чтож надеюсь что произойдёт раскол на GnomeOS/Redhat и Gentoo/Devuan.
Правда что то этот процесс не очень движется.

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

В солярисе, почему-то, сохранили init, который запускает svc.startd, который и есть супервизор, с блэкджекомзависимостями, self-healing итд, вот это - unix-way.

В солярисе, почему-то, сохранили init

А вот почему?

Each service has a well-defined state (enabled, disabled, offline, maintenance) and usually a relationship to other dependent services that are required to be running on the system first. This provides a key benefit in that services can be started in parallel during system start up, resulting in a much faster boot when compared to the legacy init framework, which is only able to start processes in sequence and must wait until they complete. Each service is usually started by the SMF master restarter daemon, svc.startd

Что еще запускает init и зачем он нужен? Я так понимаю, это legacy.

Тут уж вопрос общих представлений.

Вот это и плохо,так как приведёт к перекосу в пользу тех кто платит.

Попроси другой глобус;)

И собственно кто такой RedHat

От них львиная доля кода. Они для меня авторитет.

вот у же у значительной части сообщества проблемы.

В перспективе будет осуществлен переход с X11 на Wayland. У сообщества опять будут проблемы, потому что всякие openbox/***wm и прочее-прочее перестанет работать. Зато у нас не только Wayland на подходе, но и Mir, что только добавляет проблем.

Что еще запускает init и зачем он нужен? Я так понимаю, это legacy.

Нет.

А с какого, собственно, PPID всех демонов — 1, а не 13? Это, должно быть, проигрывает systemd по фичам, поскольку svc.startd не получает оповещений о смерти запущенных им процессов.

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

$ ptree -c `pgrep netcfgd`
[process contract 1]
  1     /sbin/init
    [process contract 4]
      10    /lib/svc/bin/svc.startd
        [process contract 9]
          46    /lib/inet/netcfgd
$ ctstat -vi 9
CTID    ZONEID  TYPE    STATE   HOLDER  EVENTS  QTIME   NTIME
9       0       process owned   10      0       -       -
	cookie:                0x20
	informative event set: none
	critical event set:    core signal hwerr empty
	fatal event set:       none
	parameter set:         inherit regent
	member processes:      46
	inherited contracts:   none
	service fmri:          svc:/network/netcfg:default
	service fmri ctid:     9
	creator:               svc.startd
	aux:                   start

А, вот как. А если svc.startd упадёт, то он будет перезапущен с сохранением состояния и «очереди сообщений»?

можно провести аналогию для любителей танцполá

когда очередной дистрибутив переходит на системд, это как очередная приганичная рф страна вступает в евросоюз и нато

Да, для него есть свой рестартер. Этим и хороша модель, когда у всех родитель init, а не svc.

К этой модели есть один вопрос: как сохраняется состояние при падении svc.startd?

Допустим, он упал в процессе какого-то сложного действия (в терминах systemd: упал демон → запускается юнит, указанный в его OnFailure= → половину системы нужно остановить, ещё половину перезапустить, ну или что-то в этом духе). При этом какие-то демоны он уже успел остановить/перезапустить, а какие-то как раз в процессе перезапуска. Что делать? Как восстанавливать состояние?

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

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

Если же всё-таки будет (или есть другой способ решения этой проблемы) — тогда да, я соглашусь с тем, что это реальный недостаток в «монолитной» модели systemd.

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

Контракты и хранят состояние в ctfs(выделяется из vfs) и падение самого svc.startd ни на что не влияет. Тут подробней, и тут ещё подробнее.

Вопрос в другом. Что случается, если рестартер (svc.startd) падает во время выполнения рестарта?

Рестарта чего?

Чего-нибудь.

Допустим, упал какой-то демон. Ядро это падение поймало и сообщило svc.startd. Насколько я понял, задача svc.startd состоит в том, чтобы запустить демона обратно (или сделать что-то более сложное). Допустим, в процессе запуска демона svc.startd падает сам, успев запустить один процесс из двух. Что произойдёт в системе? Из PDF-ки это не понятно.

Начнём с того, что svc.startd не является рестартером. Состояние всех процессов и их связи отображены в /system/contract. При падении svc.startd его передёрнет рестартер, а посмотрев в /system/contract он узнает, что нужный процесс уже запущен и не надо ничего делать.

Пардон, видимо, я некорректно понял терминологию.

svc.startd — это «Solaris service manager»? Он сам вообще что-то перезапускает? Из параграфа «contracts and restarters», видимо, ответ положительный на оба вопроса, но всё же хотелось бы уточнить.

я пропустил слово «единственным».

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

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

и показать pstree

я понимаю, по ссылкам ходить не Ъ, но ты всё же сходи. а если ты ещё и тред почитаешь начиная с того односложного ответа... :)
в общем, если ты посмотришь на вывод ps, что я приложил, то увидишь PPID инита почти у всех. ядро запускает инит, тот запускает svc.startd и svc на основании контракта с инитом начинает запускать от него демоны, как-то так вкратце.

Да если бы просек!:) И даже по ссылкам я хожу, и треды читаю - круглый молодец я.) Просто не хотелось отвечать на надуманный ответ и как я теперь вижу, правильно.

Из листинга ps ведь совершенно не следет, что процессы запустил не init, а svc.startd, после чего PPID был подменен.

Т.е. по факту сам init запускает всего два процесса svc.startd и svs.config.

Теперь я собственно не вижу здесь большой разницы между SMF и systemd. Systemd может быть запущен прямо как /sbin/init. Он также дробится на функциональные части logind, networkd, jounald... То, с чего мы начали, это противоречит ли функция демон-супервизора концепции UNIX way. Концепция предполагает, что мы имеем несколько утилит, рекомбинация которых позволяет достичь большей гибкости (эффективности). В нашем случае я не очень понимаю, с чем мы должны рекомбинировать демон-супервизор. Мы хотим использовать альтернативную имплементацию? Нет. Мы хотим вставить какой-то процессинг, пайпы? Нет.

Ты, вроде, хочешь сказать, что если svc.startd упадет, то маленький, но очень гордый и безглючный init его перезапустит, а init в исполнении systemd жирный и ненадежный. Типа мониторинг за мониторингом. Ну не знаю...

Тут вообще всё сложнее.

Насколько я смог понять ( EvgGad_303, так?), солярочный супервизор позволяет ещё меньший набор реакций на сбои: только перезапуск. В то время как systemd просто запускает произвольный указанный юнит (OnFailure=). Все остальные же действия в солярке (перевести систему в другой режим, етц) выполняются отдельными демонами, у которых свои наборы контрактов и так далее.

И net result этой инфраструктуры в том, что каждый из солярочных «менеджеров чего-нибудь» имеет очень ограниченную задачу, и в случае падения его можно будет просто перезапустить и он (благодаря ядру с его контрактами) продолжит с того места, где упал. Так?

Как я сказал, принципиальной разницы не вижу. systemd-init пытается покрыть десктопные надобности (коммуникация со спец шинами и т.д.), а солярисовский ориентирован на сервера, соответственно проще. Отсюда разница в жире. Когда я очень давно смотрел SMF, лично у меня сложилось очень стройное представление - «все просто и понятно!». А на systemd я гляжу-гляжу..

Ты хочешь сказать, что то, что в солярисе сделано на уровне демонов, в systemd сделано на уровне юнитов?

Вроде того. Более того, в солярочном ядре есть концепция контрактов, а в линуксе такой нет, и её роль выполняет механизм OnFailure= в systemd.

Про контракты я понял. Я также прочитал где-то, что пока он их загружает при запуске ОС, проходит много времени.

А насчет OnFailur... какой же это механизм? это опция.:) Механизм свой.

Не понял. Называй как угодно — механизм, концепция, набор директив... Под «механизмом» я имею в виду совокупность средств, которые есть в systemd с целью реагирования на сбои юнитов.

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

Хорошо, тогда я не понял, что значит «в солярке оно сразу в ядре есть». Что значит «сразу»? Т.е. пришел Гарри Потер, махнул палочкой и появлась на свет солярка «сразу с контрактами»? Программерам дали ТЗ и они сели и долго-долго писали.

Теперь пришла очередь линукса. Тоже написали код. Но.

Допустим, контракты в солярисе - это механизм на уровне ядра. Некая БД с доступом через виртуальну ФС. Классно. Солярис тупит, пока загружает ее с диска при запуске, но пофигу. Всеравно хорошо. Эта БД будет использоваться для определения порядка запуска и для зависимостей и восстановления при креше.

А у systemd другой способ определения зависимостей при старте. Для всех сервисов создаются UNIX-сокеты для обмена сообщениями. Это быстро. Потом часть зависимостей определяется автоматически, во время рантайма, когда кто-нибудь кого-нибудь дернет. Эта идея взята из launchd Mac OS X, которая мега быстро грузится, потому что это мега важно для десктопной ОС.

Теперь вторая часть. Как определять зависимости сервисов при self-healing, когда что-то упало? В Солярисе как следствие используется общая БД, которую тыркают маленькие демоны. В Linux инфа о зависимостях лежит в памяти systemd, он ее как-то собрал и как-то ее может отдавать.

«Сразу» — синоним «уже». С точки зрения юзерспейсного ПО, которое управляет запуском. Типа абстракция. Пофиг откуда, но уже есть. Это к вопросу о том, почему SMF такая хорошая, модульная и гибкая: потому что её «кишки» в ядре ОС.

Не понимаю тебя. А UNIX сокеты «уже» есть в ядре линукс и systemd их использует. Ну и что? Солярис выпускают одним большим бандлом, линукс разрабатывается по другой модели. Я тебе говорю, что systemd вобще грузится по другому принципу, а ты заладил «раз в ядре, значит, модульная и все круто». systemd зато грузится быстрее. Их вобще так сравнивать неправильно. Можно сразу сравнить ланчер для Mac OS X и SMF.

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

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

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

а у systemd эта крутая абстракция где-нибудь на уровне программного API. мы ее не видим, а она есть:) просто другой уровень. и по-моему ни в одном ядре нет какого-то механизма для перезапуска init.

а ты посмотри в инете про патчи systemd -> ядро :)

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

EvgGad_303 говорил вроде, что в солярке как раз есть. Ладно, фиг с ней, с соляркой.

а у systemd эта крутая абстракция где-нибудь на уровне программного API.

Ну, ничего похожего там нет, в т. ч. внутри. Контракты (aka межпроцессные оповещения о сбоях) не имеет смысла имплементить в юзерспейсе, потому что всё равно получаем god process, при падении которого всё необратимо просирается. А может быть, и имеет смысл, просто Леннарт подумал и сказал «хрен с ним, не будем переусложнять».

Ты про kdbus? Оно вообще не о том.

солярочный супервизор позволяет ещё меньший набор реакций на сбои: только перезапуск.

У каждого сервиса есть описывающий файл ака манифест в дебрях /lib/svc, в нём указываются зависимости, в каком порядке и тд и сколько раз пытаться перезапускать, перед тем как пометить сервис maintenance, или какие реакции ты имеешь ввиду?

Да, я имею в виду именно такие реакции. В systemd, к примеру, можно в OnFailure= указать произвольный юнит (и отдельно задать политику перезапуска). А здесь — только перезапуск, так?

Некая БД с доступом через виртуальну ФС

Это не бд, эта pseudofs отражена в /system/contract, как /proc.

Эта БД будет использоваться для определения порядка запуска и для зависимостей и восстановления при креше.

Нет, все сервисы описаны файлами в /lib/svc. Там же есть и бд.

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

Это не бд, эта pseudofs отражена в /system/contract, как /proc.

Я понимаю.:) Я не подразумевал, что используется Oracle SQL.:) Данные в памяти упорядочены для поиска и я для простоты разговора назвал их БД.:)

Нет, все сервисы описаны файлами в /lib/svc. Там же есть и бд.

Вот всю совокупность этих данных я и назвал в общем - БД.:) Главное, что эти данные целостные и есть их полноценное представление на диске. В отличие от systemd, где часть этих данных определяет процессом запуска и в полном виде существуют только в памяти.

Это отличие в устройстве мне показалось принципиальным и интересным. Более интересным, чем в какой именно памяти они потом хранятся. И более принципиальным, чем как именно разбит функционал между init и демонами.

В основном логи нужны к отдельным демонам

Это Windows-way. К сожалению, авторы journalctl, видимо, так и думали: «Я знаю лучше, что вам надо».

Утилита действительно пытается взять на себя функции сразу нескольких: tail, head, еще что-то. Это действительно неудобно.

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

И третья проблема: невозможно вручную удалить какие-то ненужные логи!

В systemd, к примеру, можно в OnFailure= указать произвольный юнит

Зато в SMF гораздно проще произвести _массовую_ конфигурацию такого рода:

svccfg setnotify -g maintenance mailto:admin@mycompany.com

Теперь уведомление будут работать для всех служб. А в systemd требуется редактировать отдельно каждый файл.

И третья проблема: невозможно вручную удалить какие-то ненужные логи!

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

и еще systemd сложно использовать без shell complition. если cat /var/log...[tab] и /etc/init.d/...[tab] дополняется всегда, то искать правильный blabla.service без помощи дополнения уже неудобно.

Ок, это фича для продакшена и проблема для тестового сервера. Было бы логично, если бы это можно было включить-выключить (как selinux). Но возможность удаления похоже отсутствует по принципу «я знаю лучше, что вам надо».

По поводу удобства systemd. В качестве вопроса на засыпку предлагаю вопрос, как отключить старт dbus-daemon.

отключить старт dbus-daemon

systemd

Никак, он через него работает. Да и зачем это нужно, когда большинство софта через него общается?