Процессы, сигналы и fork — бесплатный тест онлайн

Вопрос 1 из 30

Какое утверждение точно описывает поведение фрагмента «Создание процесса» с `$pid`, `fork` и `child_work`?

my $pid=fork();
die 'fork' unless defined $pid;
if($pid==0){ child_work(); exit 0 }
parent_work($pid);

Даже без правки фрагмент уже даёт гарантию исправленного варианта: Ошибка проверяется отдельно до сравнения PID. Fork возвращает undef при ошибке, 0 в дочернем процессе и PID ребёнка в родителе; ветви обязаны быть разделены. Fork не возвращает undef при ошибке, 0 в дочернем процессе и PID ребёнка в родителе; ветви обязаны быть разделены. Непосредственным итогом выполнения будет: undef от неудачного fork тоже ложно и будет принят за дочернюю ветвь. В показанном случае решающим становится только ограничение: В многопоточном процессе fork особенно опасен: в ребёнке остаётся только вызвавший поток, а состояния библиотек могут быть неконсистентны.

Вопрос 2 из 30

Как точнее всего описать действие фрагмента с `$pid`, `$status` и `wait`?

my $pid=wait();
my $status=$?;
say $status >> 8;

Wait возвращает PID завершившегося ребёнка, а обычный код выхода находится в старших восьми битах $?. В этой версии кода возникает другой результат: Ненулевой $? может означать код выхода, сигнал или ошибку wait; простая проверка теряет причину. Исходная реализация уже содержит нужную защиту: Статус разбирается на ошибку ожидания, сигнал и обычный код завершения. Wait не возвращает PID завершившегося ребёнка, а обычный код выхода находится в старших восьми битах $?. Поведение кода сводится к одной границе механизма: WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать всех завершившихся детей.

Вопрос 3 из 30

Как ведёт себя участок «Сигналы» при выполнении?

local $SIG{TERM}=sub { $stop=1 };
while(!$stop){ do_one_unit() }
cleanup();

Обработчик лишь ставит флаг, а безопасная остановка происходит между единицами работы. Обработчик лишь ставит флаг, а безопасная остановка не происходит между единицами работы. Главным результатом фрагмента станет следующее: Сложная очистка прямо в обработчике может вклиниться в прикладной код в неудобной точке, повторно войти в библиотеку и скрыть исходное состояние. Единственное существенное правило этого запуска — следующая оговорка: Сигналы могут объединяться и приходить между любыми двумя операциями; их нельзя считать надёжной очередью событий. Показанная версия изначально работает как исправленная: Игнорирование SIGPIPE позволяет обработать ошибку записи как обычный результат print.

Вопрос 4 из 30

Что непосредственно следует из показанного кода с `$pid` и `fork`?

for(1..10){ my $pid=fork(); exit 0 unless $pid }
sleep 60;

Главным результатом фрагмента станет следующее: На некоторых системах это включает автоматический сбор, но лишает приложение кодов выхода и имеет платформенные нюансы. Родитель не вызывает wait, поэтому завершившиеся дети остаются зомби до сбора статуса или завершения родителя. Показанная версия изначально работает как исправленная: Обработчик собирает всех уже завершившихся детей, а не только одного. Итог этого фрагмента полностью задаёт следующая оговорка: Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен. Родитель не вызывает wait, поэтому завершившиеся дети остаются зомби до сбора статуса или завершения дочернего процесса.

Вопрос 5 из 30

Какое описание не теряет важный побочный эффект участка с `getppid`?

say join ' ', $$, getppid(), scalar localtime;

В блоке «Наблюдаемость и диагностика» печатается состояние данные блока «Наблюдаемость и диагностика» до вычисления последнего выражения, а его результат отбрасывается. Для результата здесь достаточно учесть лишь такое условие: Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной. Главным результатом фрагмента станет следующее: Сообщение не содержит PID ребёнка, задания, статуса и длительности, поэтому его нельзя связать с работой. PID, PPID и время дают базовую привязку события к процессу, но для расследования нужны также идентификатор задачи и стадия. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Структурированное событие связывает процесс, задачу, результат и время.

Вопрос 6 из 30

Не запуская фрагмент «Надёжность в эксплуатации», выберите точное описание его работы.

my $pid=fork();
if($pid==0){ exec @cmd; die "exec: $!" }
waitpid($pid,0);

Списковый exec запускает программу без оболочки, а ошибка exec явно завершает дочернюю ветвь. Списковый exec запускает программу без оболочки, а ошибка exec неявно завершает дочернюю ветвь. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Списковая форма не требует shell и позволяет отдельно разобрать статус. Показанный участок сработает иначе: Строковая команда может пройти через shell и интерпретировать метасимволы аргумента. Единственное существенное правило этого запуска — следующая оговорка: kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов.

Вопрос 7 из 30

Что в этом коде нарушает ожидаемое поведение?

my $pid=fork();
child_work() unless $pid;

Риск появляется после применения рекомендуемой правки: Ошибка проверяется отдельно до сравнения PID. Defined от неудачного fork тоже ложно и будет принят за дочернюю ветвь. Undef от неудачного fork тоже ложно и будет принят за дочернюю ветвь. Показанный сбой объясняется не кодом, а таким пределом механизма: В многопоточном процессе fork особенно опасен: в ребёнке остаётся только вызвавший поток, а состояния библиотек могут быть неконсистентны. Дефект объясняется базовым поведением фрагмента: fork возвращает undef при ошибке, 0 в дочернем процессе и PID ребёнка в родителе; ветви обязаны быть разделены.

Вопрос 8 из 30

Какой риск связан именно с операциями `$pid`, `waitpid` и `retry`?

waitpid($pid,0);
if($?){ retry() }

Ненулевой $? может означать код выхода, сигнал или ошибку wait; простая проверка теряет причину. Ненулевой $? может означать код выхода, сигнал или успех wait; простая проверка теряет причину. Нежелательное поведение вводит предлагаемое решение: Статус разбирается на ошибку ожидания, сигнал и обычный код завершения. Основная проблема здесь — сам результат штатного случая: wait возвращает PID завершившегося ребёнка, а обычный код выхода находится в старших восьми битах $?. Ненулевой $? не может означать код выхода, сигнал или ошибку wait; простая проверка теряет причину.

Вопрос 9 из 30

Где находится первопричина возможного сбоя в коде с `$SIG`, `$lock` и `save_all`?

$SIG{TERM}=sub { save_all(); unlink $lock; exit };

Сложная очистка прямо в обработчике может вклиниться в прикладной код в неудобной точке, повторно войти в библиотеку и скрыть исходное состояние. Сложная очистка прямо в обработчике не может вклиниться в прикладной код в неудобной точке, повторно войти в библиотеку и скрыть исходное состояние. Причина сбоя совпадает с обычным результатом примера: Обработчик лишь ставит флаг, а безопасная остановка происходит между единицами работы. Источником дефекта становится само изменение: Игнорирование SIGPIPE позволяет обработать ошибку записи как обычный результат print. Показанный сбой объясняется не кодом, а таким пределом механизма: Сигналы могут объединяться и приходить между любыми двумя операциями; их нельзя считать надёжной очередью событий.

Вопрос 10 из 30

Где находится первопричина возможного сбоя в коде с `$SIG`?

$SIG{CHLD}='IGNORE';

На некоторых системах это включает автоматический сбор, но лишает приложение кодов выхода и имеет платформенные нюансы. Показанный код уже соблюдает правило «Стратегия сбора детей выбирается по нужде в статусах: явный wait/waitpid или осознанное автоматическое игнорирование», поэтому отдельного дефекта нет. Главный риск этого участка задаёт другое ограничение механизма: Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен. Риск возникает уже в обычном результате: Родитель не вызывает wait, поэтому завершившиеся дети остаются зомби до сбора статуса или завершения родителя. Сбой создаёт именно предложенное исправление: Обработчик собирает всех уже завершившихся детей, а не только одного.

Вопрос 11 из 30

Где находится первопричина возможного сбоя в коде с ключевыми операциями?

warn "worker failed";

Показанный сбой объясняется не кодом, а таким пределом механизма: Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной. Сообщение не содержит PID ребёнка, задания, статуса и длительности, поэтому его нельзя связать с работой. Проблема возникает в исправленном варианте: Структурированное событие связывает процесс, задачу, результат и время. Дефект объясняется базовым поведением фрагмента: PID, PPID и время дают базовую привязку события к процессу, но для расследования нужны также идентификатор задачи и стадия. Показанный код уже соблюдает правило «Наблюдаемость процесса строят на корреляционных идентификаторах, метриках времени и числа детей, статусах выхода и ограниченном журнале сигналов», поэтому отдельного дефекта нет.

Вопрос 12 из 30

Какой дефект проявится в варианте «Надёжность в эксплуатации» с `$tool`, `$arg` и `system`?

system("$tool $arg");

Строковая команда не может пройти через shell и интерпретировать метасимволы аргумента. Существенная проблема здесь связана с иной границей: kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов. Нежелательное поведение вводит предлагаемое решение: Списковая форма не требует shell и позволяет отдельно разобрать статус. Причина сбоя совпадает с обычным результатом примера: Списковый exec запускает программу без оболочки, а ошибка exec явно завершает дочернюю ветвь. Строковая команда может пройти через shell и интерпретировать метасимволы аргумента.

Вопрос 13 из 30

Как правка с `$pid`, `defined` и `fork` меняет поведение на неудобном входе?

defined(my $pid = fork()) or die "fork: $!";
if ($pid == 0) {
    run_child();
    exit 0;
}

Правка лишь воспроизводит исходное поведение: fork возвращает undef при ошибке, 0 в дочернем процессе и PID ребёнка в родителе; ветви обязаны быть разделены. Ошибка проверяется отдельно до сравнения PID. Польза изменения состоит только в снятии такой оговорки: В многопоточном процессе fork особенно опасен: в ребёнке остаётся только вызвавший поток, а состояния библиотек могут быть неконсистентны. Изменение формы записи само по себе обеспечивает правило «После fork оба процесса продолжают с копией памяти и открытых дескрипторов; соединения и буферы нужно переоценить в каждой ветви». После изменения сохраняется прежний дефект: undef от неудачного fork тоже ложно и будет принят за дочернюю ветвь.

Вопрос 14 из 30

Как правка с `$pid`, `$status` и `$exit` меняет поведение на неудобном входе?

waitpid($pid, 0);
my $status = $?;
if ($status == -1) {
    die "waitpid: $!";
} elsif ($status & 127) {
    warn 'child died from signal ' . ($status & 127);
} else {
    my $exit = $status >> 8;
    record_exit_code($exit);
}

После изменения сохраняется прежний дефект: Ненулевой $? может означать код выхода, сигнал или ошибку wait; простая проверка теряет причину. После правки перестаёт проявляться предел механизма: WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать всех завершившихся детей. Правка лишь воспроизводит исходное поведение: wait возвращает PID завершившегося ребёнка, а обычный код выхода находится в старших восьми битах $?. Статус разбирается на ошибку ожидания, сигнал и обычный код завершения. Статус разбирается на успех ожидания, сигнал и обычный код завершения.

Вопрос 15 из 30

Как правка с `$SIG`, `$ok` и `$sock` меняет поведение на неудобном входе?

local $SIG{PIPE}='IGNORE';
my $ok=print {$sock} $data;

После правки перестаёт проявляться предел механизма: Сигналы могут объединяться и приходить между любыми двумя операциями; их нельзя считать надёжной очередью событий. После изменения сохраняется прежний дефект: Сложная очистка прямо в обработчике может вклиниться в прикладной код в неудобной точке, повторно войти в библиотеку и скрыть исходное состояние. Правка лишь воспроизводит исходное поведение: Обработчик лишь ставит флаг, а безопасная остановка происходит между единицами работы. Игнорирование SIGPIPE позволяет обработать ошибку записи как обычный результат print. Игнорирование SIGPIPE позволяет обработать успех записи как обычный результат print.

Вопрос 16 из 30

Почему пограничный случай больше не теряется в участке с `$SIG` и `waitpid`?

$SIG{CHLD}=sub { 1 while waitpid(-1, WNOHANG)>0 };

Польза изменения состоит только в снятии такой оговорки: Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен. Обработчик собирает только первого уже завершившихся детей, а не только одного. После изменения сохраняется прежний дефект: На некоторых системах это включает автоматический сбор, но лишает приложение кодов выхода и имеет платформенные нюансы. Обработчик собирает всех уже завершившихся детей, а не только одного. Правка лишь воспроизводит исходное поведение: Родитель не вызывает wait, поэтому завершившиеся дети остаются зомби до сбора статуса или завершения родителя.

Вопрос 17 из 30

Что изменилось в работе фрагмента «Наблюдаемость и диагностика»?

log_event(event=>'child_exit',pid=>$pid,job=>$job,status=>$status,elapsed=>$dt);

Изменение формы записи само по себе обеспечивает правило «Наблюдаемость процесса строят на корреляционных идентификаторах, метриках времени и числа детей, статусах выхода и ограниченном журнале сигналов». Структурированное событие связывает процесс, задачу, результат и время. Правка лишь воспроизводит исходное поведение: PID, PPID и время дают базовую привязку события к процессу, но для расследования нужны также идентификатор задачи и стадия. Гарантию исправления даёт исчезновение ограничения: Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной. После изменения сохраняется прежний дефект: Сообщение не содержит PID ребёнка, задания, статуса и длительности, поэтому его нельзя связать с работой.

Вопрос 18 из 30

Как правка с `$tool`, `@args` и `$s` меняет поведение на неудобном входе?

system {$tool} $tool, @args;
my $s=$?;

Списковая форма не требует shell и позволяет отдельно разобрать статус. После изменения сохраняется прежний дефект: Строковая команда может пройти через shell и интерпретировать метасимволы аргумента. Изменение формы записи само по себе обеспечивает правило «Надёжная эксплуатация требует лимита параллелизма, тайм-аута, сбора статуса, завершения группы процессов и идемпотентной повторной попытки». Правка лишь воспроизводит исходное поведение: Списковый exec запускает программу без оболочки, а ошибка exec явно завершает дочернюю ветвь. После правки перестаёт проявляться предел механизма: kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов.

Вопрос 19 из 30

Какой вывод объединяет результат, дефект и исправление в теме «Создание процесса»?

После fork оба процесса продолжают с копией памяти и открытых дескрипторов; соединения и буферы нужно переоценить в каждой ветви. Один приём полностью закрывает тему: Ошибка проверяется отдельно до сравнения PID. После fork оба процесса продолжают с копией памяти и открытых дескрипторов; соединения и буферы не нужно переоценить в каждой ветви. Общее правило темы «Создание процесса» сводится к частному результату: fork возвращает undef при ошибке, 0 в дочернем процессе и PID ребёнка в родителе; ветви обязаны быть разделены. Всю тему можно представить как защиту от одного отказа: undef от неудачного fork тоже ложно и будет принят за дочернюю ветвь.

Вопрос 20 из 30

Какое правило отделяет семантику Perl от случайно удачного запуска?

Правило «Родитель обязан собирать статус детей и связывать его с конкретной задачей, иначе теряется результат и возникают зомби» гарантирует, что ограничение «WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать всех завершившихся детей» больше не проявится. Общее правило темы можно свести к предотвращению одного сбоя: Ненулевой $? может означать код выхода, сигнал или ошибку wait; простая проверка теряет причину. Родитель обязан собирать статус детей и связывать его с конкретной задачей, иначе теряется результат и возникают зомби. Общее правило темы «Ожидание дочерних процессов» сводится к частному результату: wait возвращает PID завершившегося ребёнка, а обычный код выхода находится в старших восьми битах $?. Один приём полностью закрывает тему: Статус разбирается на ошибку ожидания, сигнал и обычный код завершения.

Вопрос 21 из 30

Какой вывод стоит перенести из учебного примера «Сигналы» в рабочий код?

Общее правило темы «Сигналы» сводится к частному результату: Обработчик лишь ставит флаг, а безопасная остановка происходит между единицами работы. Для всех случаев темы подходит одно изменение: Игнорирование SIGPIPE позволяет обработать ошибку записи как обычный результат print. Главный ориентир — не допустить следующую ситуацию: Сложная очистка прямо в обработчике может вклиниться в прикладной код в неудобной точке, повторно войти в библиотеку и скрыть исходное состояние. Обработчик сигнала должен быть коротким: выставить флаг, записать минимальный маркер или инициировать контролируемую отмену. Обработчик сигнала не должен быть коротким: выставить флаг, записать минимальный маркер или инициировать контролируемую отмену.

Вопрос 22 из 30

На что следует опираться при ревью кода по теме «Зомби-процессы»?

Правило «Стратегия сбора детей выбирается по нужде в статусах: явный wait/waitpid или осознанное автоматическое игнорирование» гарантирует, что ограничение «Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен» больше не проявится. Общее правило темы «Зомби-процессы» сводится к частному результату: Родитель не вызывает wait, поэтому завершившиеся дети остаются зомби до сбора статуса или завершения родителя. Стратегия сбора детей выбирается по нужде в статусах: явный wait/waitpid или осознанное автоматическое игнорирование. Главный ориентир — не допустить следующую ситуацию: На некоторых системах это включает автоматический сбор, но лишает приложение кодов выхода и имеет платформенные нюансы. Общее правило исчерпывается единственной правкой: Обработчик собирает всех уже завершившихся детей, а не только одного.

Вопрос 23 из 30

Какую закономерность проверяют задания темы «Наблюдаемость и диагностика»?

Правило «Наблюдаемость процесса строят на корреляционных идентификаторах, метриках времени и числа детей, статусах выхода и ограниченном журнале сигналов» гарантирует, что ограничение «Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной» больше не проявится. Достаточно применить следующее исправление: Структурированное событие связывает процесс, задачу, результат и время. Всю тему можно представить как защиту от одного отказа: Сообщение не содержит PID ребёнка, задания, статуса и длительности, поэтому его нельзя связать с работой. Наблюдаемость процесса строят на корреляционных идентификаторах, метриках времени и числа детей, статусах выхода и ограниченном журнале сигналов. Общее правило темы «Наблюдаемость и диагностика» сводится к частному результату: PID, PPID и время дают базовую привязку события к процессу, но для расследования нужны также идентификатор задачи и стадия.

Вопрос 24 из 30

Какое положение темы «Надёжность в эксплуатации» помогает выбрать надёжную реализацию?

Один приём полностью закрывает тему: Списковая форма не требует shell и позволяет отдельно разобрать статус. Общее правило темы «Надёжность в эксплуатации» сводится к частному результату: Списковый exec запускает программу без оболочки, а ошибка exec явно завершает дочернюю ветвь. Надёжная эксплуатация требует лимита параллелизма, тайм-аута, сбора статуса, завершения группы процессов и идемпотентной повторной попытки. Для ревью достаточно исключить частный дефект: Строковая команда может пройти через shell и интерпретировать метасимволы аргумента. Правило «Надёжная эксплуатация требует лимита параллелизма, тайм-аута, сбора статуса, завершения группы процессов и идемпотентной повторной попытки» гарантирует, что ограничение «kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов» больше не проявится.

Вопрос 25 из 30

Какое предостережение по теме «Создание процесса» нельзя заменить включением strict и warnings?

Базовое правило «После fork оба процесса продолжают с копией памяти и открытых дескрипторов; соединения и буферы нужно переоценить в каждой ветви» автоматически снимает указанную границу. В многопоточном процессе fork особенно опасен: в ребёнке остаётся только вызвавший поток, а состояния библиотек могут быть неконсистентны. Режимы strict и warnings полностью снимают это ограничение. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Ограничение «В многопоточном процессе fork особенно опасен: в ребёнке остаётся только вызвавший поток, а состояния библиотек могут быть неконсистентны» исчезает, если обычный пример один раз завершился успешно.

Вопрос 26 из 30

Какое предостережение по теме «Ожидание дочерних процессов» нельзя заменить включением strict и warnings?

WNOHANG позволяет опрос без блокировки, но цикл не должен избегать активного ожидания и собирать всех завершившихся детей. WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать только первого завершившихся детей. Базовое правило «Родитель обязан собирать статус детей и связывать его с конкретной задачей, иначе теряется результат и возникают зомби» автоматически снимает указанную границу. Ограничение «WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать всех завершившихся детей» исчезает, если обычный пример один раз завершился успешно. WNOHANG позволяет опрос без блокировки, но цикл должен избегать активного ожидания и собирать всех завершившихся детей.

Вопрос 27 из 30

Какое предостережение по теме «Сигналы» нельзя заменить включением strict и warnings?

Базовое правило «Обработчик сигнала должен быть коротким: выставить флаг, записать минимальный маркер или инициировать контролируемую отмену» автоматически снимает указанную границу. При strict и warnings отдельная проверка этой оговорки не требуется. Сигналы могут объединяться и приходить между любыми двумя операциями; их нельзя считать надёжной очередью событий. Ограничение «Сигналы могут объединяться и приходить между любыми двумя операциями; их нельзя считать надёжной очередью событий» исчезает, если обычный пример один раз завершился успешно. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код.

Вопрос 28 из 30

Какое ограничение блока «Зомби-процессы» следует проверять отдельным примером?

Ограничение «Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен» исчезает, если обычный пример один раз завершился успешно. Один SIGCHLD может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен. Базовое правило «Стратегия сбора детей выбирается по нужде в статусах: явный wait/waitpid или осознанное автоматическое игнорирование» автоматически снимает указанную границу. Один SIGCHLD не может соответствовать нескольким детям, поэтому один вызов waitpid недостаточен. В актуальной версии Perl эта граница больше не действует.

Вопрос 29 из 30

Какое утверждение о теме «Наблюдаемость и диагностика» не приписывает механизму лишних гарантий?

Базовое правило «Наблюдаемость процесса строят на корреляционных идентификаторах, метриках времени и числа детей, статусах выхода и ограниченном журнале сигналов» автоматически снимает указанную границу. Ограничение «Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Отладочный дамп всего окружения не может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной. Отладочный дамп всего окружения может раскрыть секреты; наблюдаемость должна быть полезной и минимально чувствительной.

Вопрос 30 из 30

Что остаётся верным о теме «Надёжность в эксплуатации», если учитывать контекст, отказ и побочный эффект?

Kill TERM одному PID не обязательно остановит его потомков; для дерева команд не может понадобиться отдельная группа процессов. Ограничение «kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Надёжная эксплуатация требует лимита параллелизма, тайм-аута, сбора статуса, завершения группы процессов и идемпотентной повторной попытки» автоматически снимает указанную границу. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Kill TERM одному PID не обязательно остановит его потомков; для дерева команд может понадобиться отдельная группа процессов.