From: Simone Piccardi Date: Mon, 23 Sep 2002 18:19:44 +0000 (+0000) Subject: Orphaned process group X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=060f402cc8c96141f1c21eabda3a156d31bd0383;p=gapil.git Orphaned process group --- diff --git a/session.tex b/session.tex index 7569843..bb207eb 100644 --- a/session.tex +++ b/session.tex @@ -237,7 +237,7 @@ componente. Inoltre la funzione distacca il processo da ogni terminale di controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse in precedenza associato. -La funzione ha successo soltanto se il processo non è già leader di un + funzione ha successo soltanto se il processo non è già leader di un \textit{process group}, per cui per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che, avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci @@ -361,41 +361,79 @@ file descriptor originario; un caso tipico accetta la redirezione sullo standard input di un file da decrittare, ma deve poi leggere la password dal terminale. -Un'altra caratteristica del gruppo di \textit{foreground} è che il kernel -invia i segnali generati dai caratteri speciali del terminale (\cmd{C-z}, -\cmd{C-c}, \cmd{C-y} e \verb|C-\|, che generano rispettivamente -\macro{SIGTSTP}, \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}), solo ai -processi che ne fanno parte. - -In caso di \textit{hungup} del terminale (si chiama così una condizione di -blocco del terminale, letteralmente sarebbe \textsl{impiccagione}), ad esempio -se si interrompe la linea, o va giù la rete, il kernel provvederà ad inviare -il segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata -in questo caso è la terminazione del processo, il problema è cosa accade agli -altri processi nella sessione, che non han più un processo di controllo che -possa gestire l'accesso al terminale, che potrebbe essere riutilizzato per -qualche altra sessione. - -Lo standard POSIX.1 prevede che se il processo di controllo termina (che ciò -avvenga per un \textit{hungup} del terminale o meno) venga inviato un segnale -di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo essi -potranno essere avvisati che non esiste più un processo in grado di gestire il -terminale (di norma tutto ciò comporta la terminazione anche di questi -ultimi). - -Restano però i processi in background, che, per quanto detto, potrebbero -proseguire la loro esecuzione e, fintanto che non accedono al terminale non ci -sarebbero problemi. In caso di accesso però potrebbero (in seguito al -comportamento standard appena descritto) bloccarsi, e restare tali per sempre, -dato che non c'è più il processo di controllo. Questa situazione è quella che -in cui si ha un cosiddetto \textit{orphaned process group}, che POSIX.1 -definisce come un \textit{process group} i cui processi hanno come padri o -altri processi nel gruppo, o processi fuori della sessione. - -Si ricordi che un processo è detto orfano quando il suo padre è terminato, nel -qual caso viene adottato da \cmd{init}, che è al di fuori di qualunque -sessione, - +Un'altra caratteristica del terminale di controllo usata nel job control è che +utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z}, +\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà si che il kernel invii i +corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT}, +\macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a +tutti i processi del gruppo di \textit{foreground}; in questo modo la shell +può gestire il blocco e l'interruzione dei vari comandi. + +Per completare la trattazione delle caratteristiche del job control legate al +terminale di controllo, occorre prendere in considerazione i vari casi legati +alla terminazione anomala dei processi, che sono di norma gestite attraverso +il segnale \macro{SIGHUP}. Il nome del segnale deriva da \textit{hungup}, +termine che viene usato per indicare la condizione in cui il terminale diventa +inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}). + +Quando si verifica questa condizione, ad esempio se si interrompe la linea, o +va giù la rete o più semplicemente si chiude forzatamente la finestra di +terminale su cui si stava lavorando, il kernel provvederà ad inviare il +segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata in +questo caso è la terminazione del processo, il problema che si pone è cosa +accade agli altri processi nella sessione, che non han più un processo di +controllo che possa gestire l'accesso al terminale, che potrebbe essere +riutilizzato per qualche altra sessione. + +Lo standard POSIX.1 prevede che quando il processo di controllo termina, che +ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si +potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un +segnale di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo +essi potranno essere avvisati che non esiste più un processo in grado di +gestire il terminale (di norma tutto ciò comporta la terminazione anche di +questi ultimi). + +Restano però gli eventuali processi in background, che non ricevono il segnale +(in effetti se il terminale non serve più potrebbero proseguire fino al +completamento della loro esecuzione). Il problema si pone per quelli che sono +bloccati, o che si bloccano nell'accesso al terminale. + +In questa situazione si ha un cosiddetto \textit{orphaned process group}; +POSIX.1 lo definisce come un \textit{process group} i cui processi hanno come +padri esclusivamente o altri processi nel gruppo, o processi fuori della +sessione. Lo standard prevede che se la terminazione di un processo fa sì che +un process group diventi orfano e se i suoi mebri sono bloccati, a tutti +vengano inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}. + +La definizione può sembrare complicata, e a prima vista non è chiaro cosa +tutto ciò abbia a che fare con il problema illustrato. Consideriamo allora +cosa avviene di norma nel \textit{job control}: una sessione viene creata con +\func{setsid} che crea anche un nuovo process group: per definizione +quest'ultimo è sempre \textsl{orfano}, dato che il padre del leader di +sessione è fuori dallo stesso. Questo è un caso limite, e non viene emesso +nessun segnale perché quanto previsto dallo standard riguarda solo i +raggruppamenti che diventano orfani alla terminazione di un processo. + +Il leader di sessione provvederà a creare nuovi process group che a questo +punto non sono orfani in quanto esso resta padre per almeno uno dei processi +del gruppo (gli altri possono derivare dal primo). Alla terminazione del +leader di sessione però avremo che, come visto in +\secref{sec:proc_termination}, tutti i suoi figli vengono adottati da +\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process +group (a meno di non aver spostato con \func{setpgid} un processo da un gruppo +ad un altro, cosa che di norma non viene fatta) crati direttamente dal leader +di sessione i quali riceveranno, nel caso siano bloccati, i due segnali, in +modo che essi vengano sbloccati da \macro{SIGCONT} e (se non vi è un gestore +opportuno) terminati da \macro{SIGHUP}. + + + + + + + che possa accorgersi +(si ricordi che per farlo occorre usare \func{waitpid}) se i processi del +\textit{process group} sono bloccati. \subsection{Dal login alla shell} @@ -513,8 +551,6 @@ ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty} per ripetere da capo tutto il procedimento. - - In generale quando con il contollo di sessione è la shell che assume il ruolo di processo di controllo, seleziona il gruppo di \textit{foregroud} e gestisce l'assegnazione dei process group ai programmi eseguiti sulla stessa riga di