Re: systemd, чтоб его

[Artem Chuprina <ran@ran.pp.ru>]

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 и не портит саму идею.