Ivan Shmakov -> debian-russian@lists.debian.org @ Wed, 17 Sep 2014 07:27:49 +0000:
AC>> Впрочем, если смотреть шире, то в данном случае это вообще AC>> замечательная и вся из себя прекрасная идея ленивых вычислений. AC>> Которая, кстати, давно частично реализована в юниксах в части AC>> сетевых взаимодействий (inetd). AC>> Но полезность inetd ограничена тем, что он, во-первых, не умеет AC>> действовать по схеме "при первом запросе поднять сервис и оставить AC>> его работать" (а это довольно часто нужно), а во-вторых, не умеет AC>> поднять зависимости. А в-третьих, тем, что он это умеет только для AC>> сети. IS>> Что примечательно, – inetd (почти уверен, — во всех его вариантах) IS>> умеет работать не занимая PID 1. Зачем сие потребовалось Systemd — IS>> совершенно не представляю. AC>> Тут скорее следует говорить о том, что inetd не выполняет функции AC>> init, поэтому не заменяет его, потому и не занимает PID 1. IS> Верно. При этом, повторюсь, — запуск процессов — вне IS> зависимости от поддержки зависимостей, Cgroups, и прочих Dbus — IS> совершенно ортогонален выполнению функций init. Примеры — все IS> варианты Inetd, Supervisor, а равно и упомянутый в [1] некий IS> Circus. Насчет ортогональности я бы попросил... Все-таки init выполняет функции корня дерева процессов - во-первых, бутстрап (запуск первых процессов), а во-вторых, сбор вымерших сиротинушек со всей системы и подметание за ними. Плюс он же, что вполне естественно ровно по причине PID 1 (т.е. заранее известно, кому именно слать сигнал) реагирует на общесистемные сигналы типа потери питания и запроса шатдауна. Хотя это уже, глядя на его man, переехало на использование /run/initctl (undocumented, судя по тому же man). Еще он отвечает за локальные логины в консоль, потому что в свое время больше некуда было засунуть запуск getty, ну, так это и осталось. IS> [1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html AC>> А systemd - выполняет, вследствие чего заменяет (ибо нафига тогда AC>> еще и init?), поэтому совершенно естественно, что PID 1 достается AC>> именно ему. IS> BTW, какие именно функции init (в смысле PID 1) берет на себя IS> Systemd? «Усыновление осиротевших процессов» и запуск условного IS> /etc/init.d/rcS при запуске системы? Так с этими задачами /уже/ IS> справляется SysV init. Для чего потребовалась заново решать эту IS> задачу «с нуля»? Скажем так, и эти тоже. С SysV init у нас сейчас в системе N различных супервизоров и запускателей процессов для разных ситуаций - сам init, inetd, dbus-daemon, *dm, ну и вот супервизоры-велосипеды. У большинства из них система зависимостей либо кривая, как у нынешнего SysV init (не у самого init, а у /etc/rc, как я понимаю), либо вообще отсутствует. Сама по себе идея причесать этот разброд и аккуратно поделить на процессы, добавив ей ленивости - это очень хорошая идея. В частности, из SysV init откровенно следует выдрать работу с логинами и с power status (последняя там особенно крива), оставив только бутстрап (в смысле, запуск супервизора с нужными параметрами и фоллбэк на случай, если он сдох), запуск шатдауна (через пинок супервизора и фоллбэк на случай, если тот сдох) и сбор сиротинушек. То, что, по слухам (сам еще не проверял, врать не буду), реализация этой идеи в systemd кривая, не делает прямее нынешний SysV init и не портит саму идею. -- 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/87tx46r366....@wizzle.ran.pp.ru
