Процесс инициализации SIGKILL (PID 1)

Question

У меня возникла странная проблема относительно отправки сигнала 9 (SIGKILL) в процесс инициализации (PID 1). Как вы знаете, SIGKILL нельзя игнорировать с помощью обработчиков сигналов. Когда я попытался отправить SIGKILL в init, я заметил, что ничего не происходит; init не прекращается. Пытаясь выяснить это поведение, я решил приложить себя к процессу init с помощью strace, чтобы лучше понять, что происходит. Теперь наступает странная часть. Если я «смотрю» на процесс init с помощью strace и отправляю SIGKILL, система выходит из строя.

Мой вопрос: почему это происходит? Почему происходит сбой системы, когда я смотрю на процесс и почему он не падает, когда меня нет? Как я уже сказал, в обоих случаях я посылаю SIGKILL для инициализации. Протестировано на CentOS 6.5, Debian 7 и Arch.

Спасибо!

Answer 1

Ядро Linux преднамеренно приводит к сбою системы, если init завершает работу (см. http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501 и, в частности, вызов panic). Поэтому, в качестве меры предосторожности, ядро ​​не будет доставлять любой фатальный сигнал init и SIGKILL не освобожденный (см http://lxr.free-electrons.com/ident?v=3.12&i=SIGNAL_UNKILLABLE) (однако, поток коды свернутый достаточно, что я не уверен, но я подозреваемого сгенерированный ядром SIGSEGV или аналогичный код).

Применение ptrace(2) (системный вызов, который использует strace) для обработки 1, по-видимому, отключает эту защиту. Это можно сказать, что это ошибка в ядре. Я недостаточно квалифицирован, чтобы копаться в коде, чтобы найти эту ошибку.

Я не знаю, применяют ли другие варианты Unix одну семантику с аварийным завершением или сигналом до init. Было бы разумным, чтобы ОС выполняла чистое завершение работы или перезагружалась, а не паника, если init заканчивается (по крайней мере, если это происходит, вызывая _exit), но, насколько я знаю, все современные варианты Unix имеют специальную систему позвоните, чтобы запросить это, вместо этого (reboot(2)).