распространение сигнала для дочерних процессов

Question

У меня есть коллекция процессов, которые я запускаю из сценария оболочки следующим образом:

#!/bin/bash
#This is a shortcut to start multiple storage services

function finish {
    alljobs=$(jobs -p)
    if [ ! -z "$alljobs" ]; then
        kill $alljobs >/dev/null 2>&1
    else
        echo "Entire trio ceased running"
    fi
}
trap finish EXIT

./storage &
P1=$!
./storage &
P2=$!
./storage &
P3=$!
wait $P1 $P2 $P3 

В настоящее время он выполняется так, как я хочу, в том случае, когда я посылаю сигнал ctrl+cСценарий отправляет этот сигнал всем моим фоновым процессам.

Однако: теперь я расширил эти программы, чтобы на основании соединений / сообщений, которые они получают от клиентов, они могли выполнять execv,убить себя и запустить новую, отдельную программу.(Любопытно, что они имитируют «мертвое» состояние сервера, запустив процесс холостого хода, который затем может получить сигналы для повторного запуска исходного процесса.)

Проблема в том, что после execv, этот новый процесс больше не отвечает на kill, отправленный сценарием bash.

Существует ли способ, позволяющий выполнению этого исходного сценария (и последующей сигнализации) также отправлять сигнал вновьexec также обрабатываете?

Answer 1

Обновление: моя проблема была полностью не связана с этим скриптом;pid запущенных / перезагруженных процессов никогда не менялось, но я непреднамеренно наследовал сигналы, которые я блокировал, в различных потоках внутри программы.Некоторые разумные звонки pthread_sigmask решили проблему.

Спасибо @Mark за подсказки о дочерних процессах;если бы было fork звонков, это был бы очень хороший подход!

Answer 2

Я предлагаю вам рассмотреть поиск дочерних процессов по родительскому pid.Более конкретно, перед тем как убить pid, найдите дочерние процессы этого pid с помощью ps и сначала убейте их.Наконец, убейте родителя.

У меня такое чувство, что есть условия гонки, которые в некоторых случаях приводят к сбою.