Почему дочерний процесс все еще жив после того, как родительский процесс был убит в Linux?

Question

Кто-то сказал мне, что когда вы убьете родительский процесс в Linux, ребенок умрет.
Но я сомневаюсь в этом.Поэтому я написал два сценария bash, где father.sh будет вызывать child.sh

Вот мой сценарий:

Теперь я запускаю bash father.sh, вымог проверить это ps -alf

Затем я убил father.sh с помощью kill -9 24588, и я предположил, что дочерний процесс должен быть прекращен, но, к сожалению, я ошибся.

Может кто-нибудь объяснить, почему?

thx

Answer 1

Нет, когда вы убиваете один процесс, он не убивает дочерние элементы.

Вы должны отправить сигнал в группу процессов , если вы хотите, чтобы все процессы для данной группычтобы получить сигнал

kill -9 -parentpid

В противном случае, сироты будут связаны с init, как показано на третьем снимке экрана (PPID ребенка стал 1).

Answer 2

Обычно убийство родителя также убивает ребенка.

Причина, по которой вы видите ребенка, который еще жив после убийства отца, заключается в том, что ребенок умрет только после того, как решит обработать событие SIGKILL.Это не должно справиться с этим сразу.В вашем сценарии выполняется команда sleep (), которая не активируется для обработки каких-либо событий до тех пор, пока не будет завершен сон.

Почему PPID # 1?Родитель умер и больше не находится в таблице процессов.child.sh не связан необъяснимым образом с инициацией сейчас.У него просто нет бегущего родителя.Сказав, что он связан с init, создается впечатление, что если мы как-нибудь покинем init, этот init сможет контролировать процесс.Это также создает впечатление, что убийство родителя сделает прародителя владельцем ребенка.Оба не соответствуют действительности.Этот дочерний процесс все еще существует в таблице процессов и выполняется, но никакие новые события, основанные на его идентификаторе процесса, не будут обрабатываться, пока он не обработает SIGKILL.Это означает, что ребенок - предзомби, ходячий мертвец, которому грозит опасность быть маркированным.

Убийство в группе процессов отличается и используется для уничтожения братьев и сестер и родителя группой процессов #.Вероятно, также важно отметить, что «уничтожение процесса» - это не «убийство» само по себе, по-человечески, когда вы ожидаете, что процесс будет уничтожен и вся память вернется, как если бы она никогда не была.Он просто посылает определенное событие, среди многих, процессу для обработки.Если процесс не обрабатывает его должным образом, то через некоторое время появится операционная система и принудительно «очистит».

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

Answer 3

-bash: kill: (-123) - Нет такого процесса

В интерактивном сеансе Terminal.app номер идентификатора группы процессов переднего плана и номер идентификатора группы фоновых процессов различаются по конструкции, когда включен режим контроля заданий / мониторинга. Другими словами, если вы выполняете фоновую команду в сеансе Terminal.app с включенным управлением заданиями, pid $! фонового процесса фактически является новым идентификатором группы процессов (pgid).

Однако в сценарии, где управление заданиями не включено, это может быть не так! Pid фонового процесса может быть не новым pgid, а обычным pid! И это то, что вызывает сообщение об ошибке -bash: kill: (-123) - No such process, пытающееся уничтожить группу процессов, но указывающее только обычный pid (вместо pgid) для команды kill.

# the following code works in Terminal.app because $! == $pgid
{
sleep 100 &
IFS=" " read -r pgid <<EOF
$(ps -p $! -o pgid=)
EOF
echo $$ $! $pgid
sleep 10
kill -HUP -- -$!
#kill -HUP --  -${pgid}  # use in script
}

Answer 4

pkill -TERM -P <ProcessID>

Это убьет и Родителя, и ребенка