Jak emulatory terminali mogą zabijać swoje dzieci po otrzymaniu SIGKILL?

Z tego, co rozumiem, nie można złapać SIGKILL. Oznaczałoby to, że proces nie ma czasu na zabicie swoich dzieci, zanim system operacyjny je zniszczy. Można to wykazać za pomocą skryptu powłoki.

#! /bin/bash

trap : SIGTERM SIGINT SIGKILL # SIGKILL is pointless.

mplayer video.avi

Zabicie go za pomocą SIGKILL pozostawia działającego mplayera.

$ kill -9 $pid

Ale podczas korzystania z emulatora terminali (xterm, Terminal, ...) dzieci zabijają się wraz z nim. Jak to jest możliwe?

$ mplayer

I zabij to:

$ kill -9 $terminal_pid

I mplayer idzie ze statkiem. Czy emulatory terminali w jakiś sposób łapią SIGKILL, czy też działa tu inna siła?

kill signals terminal-emulator

— Kevin Cox
źródło

Odpowiedzi:

Proces rozpoczęty przez xtermbędzie liderem sesji kontrolującym terminal.

Gdy terminal odejdzie, proces ten automatycznie odbiera sygnał SIGHUP (po którym następuje SIGCONT). Jest to wysyłane przez jądro w podobny sposób, jak procesy otrzymują SIGINT po naciśnięciu CTRL-C.

Ponadto powłoka może wysyłać SIGHUP do niektórych swoich dzieci po wyjściu (patrz disownniektóre powłoki, aby to wyłączyć)

— Stéphane Chazelas
źródło

Informacje o sesjach i liderach sesji: unix.stackexchange.com/questions/18166/… .

— Kevin Cox,

+1, dla disownktórego jest bardzo przydatne.

— matematyka

Odpowiedzi na twoje pytanie, dzieje się tak, ponieważ procesy te działają jako dzieci w emulatorze terminali. Zabijasz więc emulator terminala, a tym samym zabijasz wszystkie procesy potomne (ponieważ dzieci działają w tej samej grupie procesów, co kontrolujący emulator terminalu).

Zobacz na przykład:

csb@darwin[~]$ ps fauwx | grep -A6 "xfce4-terminal" | awk '{ for (i = 2; i <= 9; i++) $i="" ; print $0 }' 
csb         0:32 xfce4-terminal --geometry=271x65 --display :0.0 --role=Terminal-0x1340050-2606-1351620352 --show-menubar --show-borders --hide-toolbars --working-directory /home/csb --tab --working-directory /home/csb
csb         0:00 \_ gnome-pty-helper
csb         0:00 \_ bash
csb         0:00 | 
                  \_ ssh [redacted]
csb         0:00 \_ bash
csb         0:00 \_ ps fauwx
csb         0:00 \_ grep --color=auto -A6 xfce4-terminal
csb         0:00 \_ awk { for (i = 2; i <= 9; i++) $i="" ; print $0 }

Wszystkie te procesy działają w ramach procesów „xfce4-terminal”, więc jeśli zabiję ten proces, automatycznie zabije on wszystkie procesy potomne w grupie procesów ... w ten sam sposób, na przykład, wychodząc z okna emulatora terminala koniecznie zabij moje połączenie SSH.

Programy takie jak powłoki tworzą nowe grupy procesów, zwykle umieszczając powiązane procesy potomne w grupie. Każde zadanie jest grupą procesów. Poza jądrem powłoka manipuluje zadaniem, wysyłając sygnały do grupy procesów zadania za pomocą wywołania systemowego killpg, które dostarcza sygnał do wszystkich procesów w grupie procesów.

— Charles Boyd
źródło

-1: Zabicie rodzica nie powoduje śmierci dzieci.

— camh

— Charles Boyd,

@CharlesBoyd Ten komentarz powinien być częścią Twojej odpowiedzi.

— jordanm,

@CharlesBoyd: Dodaj to do swojej odpowiedzi, a dam Ci +1 zamiast -1. Twoja odpowiedź brzmi obecnie tak, jakby procesy potomne zostały zabite, gdy proces macierzysty został zabity (BTW, oparty na sesjach, a nie oparty na grupach procesowych).

— camh

@CharlesBoyd Rozumiem to, ale chodzi o to, w jaki sposób „manipuluje [] zadaniem, wysyłając sygnały”, gdy otrzymuje SIGKILL. W tej chwili nie widzę możliwości użycia killpgwywołania systemowego.

— Kevin Cox,

Po pierwsze, nie mogę odtworzyć odtwarzacza mp, który przeżył zabity terminal, używając xterm.

Powodem, dla którego umiera, jest to, że otrzymuje ZABYTEK po śmierci rodzica.

— tumbleweed
źródło

Nigdy nie powiedziałem, że tak, powiedziałem, że umiera, ale przetrwa, gdy jest w scenariuszu i to jest zabite.

— Kevin Cox,

Dla mnie nie przetrwa w scenariuszu.

— tumbleweed