>>>>> "AC" == Artem Chuprina <r...@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. Долгая счастливая жизнь — Гражданская Оборона
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppesaf3w....@violet.siamics.net
