Zabijanie dzieci z rodzicem

Wiem, że minęły lata, ale znalazłem proste (nieco chwiejne) rozwiązanie tego problemu. Z procesu macierzystego, owijanie wszystkich wywołań wokół bardzo prostego programu C, który wywołuje prctl (), a następnie exec () rozwiązuje ten problem na Linuksie. Nazywam to "yeshup":

#include <linux/prctl.h>
#include <signal.h>
#include <unistd.h>

int main(int argc, char **argv) {
     if(argc < 2)
          return 1;
     prctl(PR_SET_PDEATHSIG, SIGHUP, 0, 0, 0);
     return execvp(argv[1], &argv[1]);
}

Podczas spawania procesów potomnych z Pythona (lub dowolnego innego języka), możesz uruchomić "yeshup gnuchess [argments]."Przekonasz się, że gdy proces rodzica zostanie zabity, wszystkie procesy dziecka (powinny) otrzymać SIGHUP ładnie.

To działa, ponieważ Linux honoruje wywołanie prctl (nie wyczyści go) nawet po wywołaniu execvp (co efektywnie "przekształca" proces yeshup w proces gnuchess, lub jakiekolwiek polecenie, które tam podasz), w przeciwieństwie do fork().

Faktycznie odkryłem, że Twoje oryginalne podejście działało dla mnie dobrze - oto dokładny przykładowy kod, który przetestowałem:

Echoer.py

#!/bin/env python

import time
import sys
i = 0
try:
    while True:
        i += 1
        print i
        time.sleep(1)
except KeyboardInterrupt:
    print "\nechoer caught KeyboardInterrupt"
    exit(0)

ParentProc.py

#!/bin/env python

import ctypes
import subprocess
import time

libc = ctypes.CDLL('/lib64/libc.so.6')
PR_SET_PDEATHSIG = 1
SIGINT = 2
SIGTERM = 15

def set_death_signal(signal):
    libc.prctl(PR_SET_PDEATHSIG, signal)

def set_death_signal_int():
    set_death_signal(SIGINT)

def set_death_signal_term():
    set_death_signal(SIGTERM)

#subprocess.Popen(['./echoer.py'], preexec_fn=set_death_signal_term)
subprocess.Popen(['./echoer.py'], preexec_fn=set_death_signal_int)
time.sleep(1.5)
print "parentProc exiting..."

Myślałem, że podwójny widelec ma odłączyć się od terminala sterującego. Nie wiem, jak próbujesz go wykorzystać.

To hack, ale zawsze możesz zadzwonić "ps" i wyszukać nazwę procesu, który próbujesz zabić.

Widziałem bardzo paskudne sposoby "sprzątania" za pomocą rzeczy takich jak ps xuawww | grep myApp | awk '{ print $1}' | xargs -n1 kill -9

Proces klienta, jeśli zostanie popened, może złapać SIG_PIPE i umrzeć. Istnieje wiele sposobów, aby to zrobić, ale to naprawdę zależy od wielu czynników. Jeśli wrzucisz jakiś kod ping (ping do rodzica) do potomka, możesz upewnić się, że SIG_PIPE zostanie wydane po śmierci. Jeśli to złapie, a powinno, to się skończy. Potrzebujesz dwukierunkowej komunikacji, żeby to działało poprawnie... lub zawsze blokować przeciwko Klientowi jako pomysłodawca komunikacji. Jeśli nie chcesz modyfikować dziecka, zignoruj to.

Zakładając, że nie oczekujesz, że rzeczywisty interpreter Pythona będzie segfault, możesz dodać każdy PID do sekwencji, a następnie zabić przy wyjściu. Powinno to być bezpieczne dla wyjścia, a nawet nieprzewidzianych WYJĄTKÓW. Python ma możliwości wykonywania kodu wyjścia... do sprzątania.

Oto bezpieczniejsze nasty: Dołącz każdy PID potomny do pliku, w tym proces główny (osobny plik). Użyj blokowania plików. Build a Demon watchdog, który patrzy na stan flock() Twojego głównego pid. Jeśli nie jest zablokowany, zabij wszystkie PID na liście PID dziecka. Uruchom ten sam kod przy starcie.

Bardziej paskudne: Zapisz PID do plików, jak powyżej, a następnie wywołaj aplikację w pod-powłoce: (./myMaster; ./killMyChildren)

Zastanawiam się, czy znacznik PR_SET_PDEATHSIG jest czyszczony, mimo że ustawiasz go po fork (i przed exec), więc wydaje się, że z dokumentów jak nie powinien być czyszczony.

Aby przetestować tę teorię, możesz spróbować: użyj tego samego kodu do uruchomienia podprocesu, który jest napisany w C i w zasadzie po prostu wywołuje prctl(PR_GET_PDEATHSIG, &result) i wypisuje wynik.

Kolejna rzecz, którą możesz spróbować: dodanie jawnych zer dla arg3, arg4 i arg5 po wywołaniu prctl. I. E.:

>>> implant_bomb = lambda: libc.prctl(PR_SET_PDEATHSIG, TERM, 0, 0, 0)

Jest pewne ograniczenie bezpieczeństwa, które należy wziąć pod uwagę, ponieważ jeśli wywołamy setuid po execv, dziecko nie może odebrać sygnału. Pełna lista tych ograniczeń znajduje się tutaj

Powodzenia !
/ Mohamed