Re: systemd, чтоб его

[Ivan Shmakov <ivan@siamics.net>]

>>>>> Eugene Berdnikov <bd4@protva.ru> writes:
>>>>> On Tue, Sep 16, 2014 at 10:21:34PM +0000, Ivan Shmakov wrote:
>>>>> Eugene Berdnikov <bd4@protva.ru> writes:

 >>> Но быть сервисом, критичным для функционирования системы, без
 >>> всякой защиты (от пейджинга, OOM-киллера, ошибочного сигнала
 >>> и т. п.) просто глупо.

[…]

 >>> Ядро юникса такую защиту init'у предоставляет, и это правильно.

 >> Я так подозреваю, — оно может и другим процессам такую защиту
 >> предоставлять (mlockall?), пусть даже и не по-умолчанию.

 > Может, но mlockall это защита лишь от части источников риска, для
 > защиты от сигналов в юниксе API нет.

	Что значит «защита от сигналов»?  Ядро обрабатывает только два
	сигнала: SIGKILL и SIGSTOP; все остальное — процесс, в
	соответствии с собственными предпочтениями.

 >> Кроме того, на SIGSEGV оная «защита» не распространяется.  Так что
 >> маленькая ошибка в коде Systemd чревата большим kernel panic.  В
 >> отличие от Inetd или Supervisor.

 > SIGSEGV не должен приводить напрямую к kernel panic.

	Действительно, SIGSEGV можно обработать.  Но я не уверен, что
	это действительно разумно для PID 1 в общем, и реализовано в
	Systemd в частности.  Так что по факту, — SIGSEGV для PID 1
	приводит к завершению PID 1 и, следовательно, kernel panic.

 > А насчёт монолитности и гранулярности здесь пробегали ссылки — авторы
 > systemd утверждают, что их изделие поделено на множество мелких
 > частей, общающихся как процессы с определённым интерфейсом, так что
 > краха всей системы при ошибке в одном из бинарников быть не должно.

	Кроме того случая, когда ошибка происходит конкретно в коде,
	выполняемом как PID 1.

	Что, на мой взгляд, является хорошим поводом оставлять код PID 1
	как можно более простым, — может быть, даже проще, чем
	существующий SysV init.  Есть подозрение, что Systemd такого
	варианта не предлагает.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A