Re: systemd, чтоб его
>>>>> "AC" == Artem Chuprina <ran@ran.pp.ru> writes:
>>>>> Ivan Shmakov -> debian-russian@lists.debian.org:
AC> Впрочем, если смотреть шире, то в данном случае это вообще
AC> замечательная и вся из себя прекрасная идея ленивых вычислений.
AC> Которая, кстати, давно частично реализована в юниксах в части
AC> сетевых взаимодействий (inetd).
AC> Но полезность inetd ограничена тем, что он, во-первых, не умеет
AC> действовать по схеме "при первом запросе поднять сервис и оставить
AC> его работать" (а это довольно часто нужно), а во-вторых, не умеет
AC> поднять зависимости. А в-третьих, тем, что он это умеет только для
AC> сети.
IS> Что примечательно, – inetd (почти уверен, — во всех его вариантах)
IS> умеет работать не занимая PID 1. Зачем сие потребовалось Systemd —
IS> совершенно не представляю.
AC> Тут скорее следует говорить о том, что inetd не выполняет функции
AC> init, поэтому не заменяет его, потому и не занимает PID 1.
Верно. При этом, повторюсь, — запуск процессов — вне
зависимости от поддержки зависимостей, Cgroups, и прочих Dbus —
совершенно ортогонален выполнению функций init. Примеры — все
варианты Inetd, Supervisor, а равно и упомянутый в [1] некий
Circus.
[1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html
AC> А systemd - выполняет, вследствие чего заменяет (ибо нафига тогда
AC> еще и init?), поэтому совершенно естественно, что PID 1 достается
AC> именно ему.
BTW, какие именно функции init (в смысле PID 1) берет на себя
Systemd? «Усыновление осиротевших процессов» и запуск условного
/etc/init.d/rcS при запуске системы? Так с этими задачами /уже/
справляется SysV init. Для чего потребовалась заново решать эту
задачу «с нуля»?
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Reply to: