Re: systemd, чтоб его

[Ivan Shmakov <ivan@siamics.net>]

>>>>> "AC" == Artem Chuprina <ran@ran.pp.ru> writes:
>>>>> Ivan Shmakov -> debian-russian@lists.debian.org:

[…]

 IS> Что примечательно, – inetd (почти уверен, — во всех его вариантах)
 IS> умеет работать не занимая PID 1.  Зачем сие потребовалось Systemd —
 IS> совершенно не представляю.

 AC> Тут скорее следует говорить о том, что inetd не выполняет функции
 AC> init, поэтому не заменяет его, потому и не занимает PID 1.

 IS> Верно.  При этом, повторюсь, — запуск процессов — вне зависимости
 IS> от поддержки зависимостей, Cgroups, и прочих Dbus — совершенно
 IS> ортогонален выполнению функций init.  Примеры — все варианты Inetd,
 IS> Supervisor, а равно и упомянутый в [1] некий Circus.

 AC> Насчет ортогональности я бы попросил… Все-таки init выполняет
 AC> функции корня дерева процессов — во-первых, бутстрап (запуск первых
 AC> процессов),

	IOW, — запуск некоего «супервизора.»  Или даже нескольких, —
	коли вдруг пользователь пожелает.  (Или примем «One supervisor
	is enough for everyone» за аксиому?)

 AC> а во-вторых, сбор вымерших сиротинушек со всей системы и подметание
 AC> за ними.

	Секунду, — что нового в этом отношении предлагает Systemd?

 AC> Плюс он же, что вполне естественно ровно по причине PID 1
 AC> (т. е. заранее известно, кому именно слать сигнал) реагирует на
 AC> общесистемные сигналы типа потери питания и запроса шатдауна.  Хотя
 AC> это уже, глядя на его man, переехало на использование /run/initctl
 AC> (undocumented, судя по тому же man).

	«Переехала» только обработка SIGPWR; SIGINT и SIGWINCH остались.

 AC> Еще он отвечает за локальные логины в консоль, потому что в свое
 AC> время больше некуда было засунуть запуск getty, ну, так это и
 AC> осталось.

	Как уже упомянуто в обсуждении, — за это отвечают именно getty,
	отнюдь не SysV init в роли PID 1.

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

	Одно время у меня в inittab был и запуск X-сервера (ну да, — с
	-query localhost.)  По некоторому рассуждению, — запуск sshd
	может быть полезно расположить там же.

	И я едва ли соглашусь, что запуск процесса в цикле с подсчетом
	итераций и времени — существенно усложняет код PID 1.

 IS> [1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html

[…]

 AC> С SysV init у нас сейчас в системе N различных супервизоров и
 AC> запускателей процессов для разных ситуаций — сам init, inetd,
 AC> dbus-daemon, *dm, ну и вот супервизоры-велосипеды.

 AC> У большинства из них система зависимостей либо кривая, как у
 AC> нынешнего SysV init (не у самого init, а у /etc/rc, как я понимаю),
 AC> либо вообще отсутствует.

 AC> Сама по себе идея причесать этот разброд и аккуратно поделить на
 AC> процессы, добавив ей ленивости — это очень хорошая идея.  В
 AC> частности, из SysV init откровенно следует выдрать работу с
 AC> логинами

	При том, что, подчеркну, — ее там никогда и не было.

 AC> и с power status (последняя там особенно крива), оставив только
 AC> бутстрап (в смысле, запуск супервизора с нужными параметрами и
 AC> фоллбэк на случай, если он сдох), запуск шатдауна (через пинок
 AC> супервизора и фоллбэк на случай, если тот сдох) и сбор сиротинушек.
 AC> То, что, по слухам (сам еще не проверял, врать не буду), реализация
 AC> этой идеи в systemd кривая, не делает прямее нынешний SysV init и
 AC> не портит саму идею.

	Я не против идеи.  Собственно, я даже, большей частью, не против
	реализации; для меня не составило бы проблемы даже использование
	XML для конфигурационных файлов (чего Systemd не предлагает) или
	«нетекстовых» журналов (что как будто бы имеется.)  К реализации
	у меня ровно два вопроса: занятие PID 1 и (как следствие)
	невозможность одновременного использования иных систем.

	У меня, впрочем, зародилось подозрение.  «Пинок супервизора»?
	Ну дело ясное, — лучше D-Bus для этого средства не найти.

	А коль скоро SysV init его не умеет, — вот и потребовалась новая
	реализация.

	Да, судя по описанию, OpenRC пытается реализовать ровно ту же
	самую идею.  Только /без/ занятия PID 1 (что как бы намекает.)
	А равно и без жестких зависимостей от функций Linux.  (Пользуясь
	случаем, хочу напомнить, что в рамках Debian разрабатываются
	варианты системы и на основе иных ядер.  Что тоже намекает.)

-- 
FSF associate member #7257  np. Долгая счастливая жизнь — Гражданская Оборона