>>>>> Eugene Berdnikov <[email protected]> writes:
>>>>> On Tue, Sep 16, 2014 at 10:21:34PM +0000, Ivan Shmakov wrote:
>>>>> Eugene Berdnikov <[email protected]> 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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
