Что происходит с SIGINT (^ C) при отправке в perl script с детьми?

Ответ 1

Функция встроенного system Perls работает так же, как функция C (3) из стандартной библиотеки C в отношении сигналов. Если вы используете Perls-версию system() или open или backticks для труб, то родительский - тот, кто вызывает system, а не тот, который его вызвал, будет IGNORE любыми SIGINT и SIGQUIT во время работы детей. Если вы перекатили свой собственный, используя какой-либо вариант трио fork?wait:exec, тогда вы должны сами об этом подумать.

Посмотрите, что произойдет, когда вы используете system("vi somefile") и нажмите ^ C во время длительного поиска в vi: только vi принимает (нефатальный) SIGINT; родитель игнорирует его. Это правильное поведение. Вот почему C работает таким образом, и поэтому Perl работает таким образом.

Вы должны помнить, что только потому, что a ^ C отправляет SIGINT ко всем процессам в группе процессов (даже тех, которые отличаются от UID или GID), что означает не, означает, что это приводит к выходу всех этих процессов. A ^ C - это только SIGINT, означающий прерывать процесс, а не SIGKILL, предназначенный для прекращения без каких-либо вопросов.

Существует много видов программ, которые были бы неправильными, чтобы просто убить без предупреждения; редактор - это всего лишь один такой пример. Почтовая программа может быть другой. Будьте предельно осторожны в этом.

Многие виды программ выборочно игнорируют, ловушки или блокируют (означает задержку доставки) различных видов сигналов. Только поведение по умолчанию SIGINT приводит к выходу процесса. Вы можете узнать, произошло ли это, и на самом деле какой сигнал вызвал это (среди прочего) с таким кодом в традиционных операционных системах:

if ($wait_status = system("whatever")) {
    $sig_killed   = $wait_status & 127;
    $did_coredump = $wait_status & 128;
    $exit_status  = $wait_status >>  8;
    # now do something based on that...
}

Обратите внимание, что a ^ Cd vi, например, будет не иметь слово состояния ожидания, указывающее, что оно умерло от незапечатанного SIGINT, так как не было одного: он поймал его.

Иногда ваши дети пойдут и у вас есть дети за спиной. Беспощадно, но верно. Поэтому я был известен, порой, геноциду, известному и неизвестному этому потомству:

# scope to temporize (save+restore) any previous value of $SIG{HUP}
{
    local $SIG{HUP} = "IGNORE";
    kill HUP => -$$;   # the killpg(getpid(), SIGHUP) syscall
}

Это, конечно, не работает с SIGKILL или SIGSTOP, которые не поддаются IGNOREd.

Другое дело, которое вы, возможно, захотите быть осторожным, заключается в том, что перед выпуском версии 5.8 обработка сигналов в Perl исторически не была надежной безопасностью. Теперь он , но это проблема, зависящая от версии. Если вы еще не сделали этого, то вам обязательно нужно прочитать на отложенные сигналы в man-странице perlipc и, возможно, также на PERL_SIGNALS envariable в man-странице perlrun.

Ответ 2

Когда вы нажмете ^ C в окне терминала (или на любом терминале, если на то пошло), он отправит SIGINT в GROUP процесса переднего плана в этом терминале. Теперь, когда вы запускаете программу из командной строки, она обычно находится в собственной группе процессов и становится группой процессов переднего плана. По умолчанию, когда вы разыгрываете дочерний элемент, он будет в той же группе процессов, что и родительский, поэтому по умолчанию родительский (программа верхнего уровня, вызванная из командной строки), все его дети, дети-дети и т.д., А также любые внешние программы, вызываемые любым из них (которые являются всего лишь детьми), будут находиться в той же самой группе процессов, поэтому все получат сигнал SIGINT.

Однако, если какой-либо из этих детей или программ вызывает setpgrp или setpgid или setid или любой другой вызов, который заставляет процесс быть в новой группе прогресса, эти процессы (и любые дети, которые они запускают после выхода из группы процессов переднего плана ) НЕ получит SIGINT.

Кроме того, когда процесс получает SIGINT, он может не заканчиваться - он может игнорировать сигнал, или он может поймать его и сделать что-то совершенно другое. Обработчик сигнала по умолчанию для SIGINT завершает процесс, но это только значение по умолчанию, которое можно переопределить.

изменить

Из вашего обновления кажется, что все осталось в одной группе процессов, поэтому сигналы доставляются всем, так как внуки (внешние программы) выходят, но дети ловят и игнорируют SIGINT. По комментарию tchrist, похоже, что это поведение по умолчанию для perl.

Ответ 3

Если вы убьете родительский процесс, дети (и внешние запущенные программы) будут работать до тех пор, пока они не прекратятся так или иначе. Этого можно избежать, если у родителя есть обработчик сигнала, который ловит SIGINT, а затем убивает группу процессов (часто родительский pid). Таким образом, как только родитель получит SIGINT, он убьет всех его детей.

Итак, чтобы ответить на ваш вопрос, все зависит от реализации обработчика сигнала. Основываясь на вашем обновлении, кажется, что родитель действительно убивает его детей, а затем вместо того, чтобы завершать себя, он возвращается к выполнению чего-то другого (подумайте об этом как о reset вместо полной комбинации shutdown/start).