Ancora orphaned process group

diff --git a/html/stampa.html b/html/stampa.html
index ab1e2675712c391cd2a0e375a16ecef2a5278618..a7afd8289536a781cad5c50a3de9a898e5eed2be 100644 (file)
--- a/html/stampa.html
+++ b/html/stampa.html
@@ -94,7 +94,7 @@
 
            <p> <b>GaPiL</b> è scritta in LaTeX, la versione aggiornata di
                tutti i file è disponibile in tempo reale sul CVS del <A
 
            <p> <b>GaPiL</b> è scritta in LaTeX, la versione aggiornata di
                tutti i file è disponibile in tempo reale sul CVS del <A

-               HREF="http://cvs.firenze.linux.it/"> FLUG</a>, a cui potete
+               HREF="http://firenze.linux.it/">FLUG</a>, a cui potete

                accedere direttamente. La versione online è pubblicata su
                questo sito, e viene periodicamente aggiornata. </P>
 
                accedere direttamente. La versione online è pubblicata su
                questo sito, e viene periodicamente aggiornata. </P>
 


@@ -129,13 +129,22 @@
              </font>
            </b>
          </td>
              </font>
            </b>
          </td>

-         <td bgcolor="lightblue"> 
-           É disponibile l'accesso ai sorgenti completi tramite cvs anonimo;
-           per scaricare la versione corrente (che conterrà probabilmente
-           errori e imprecisioni) si deve usare il comando:
+         <td bgcolor="lightblue"> É disponibile l'accesso ai sorgenti
+           completi tramite CVS anonimo; per scaricare la versione corrente
+           (che conterrà probabilmente errori e imprecisioni) la prima volta
+           si devono usare i comandi:

            <p>
            <p>

-             cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc co gapil
+             <b>
+               cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc login
+               <br>
+               cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc co gapil
+             </b>

            </p>
            </p>

+           la password per il login è <b>anonymous</b>. Il resto si può
+           ottenere alla maniera solita. Delle brevi istruzioni sull'uso di
+           CVS le trovate <A
+           HREF="http://firenze.linux.it/~piccardi/build/node4.html"> qui.
+           </a>

          </td>
        </tr>
        <tr>
          </td>
        </tr>
        <tr>

diff --git a/prochand.tex b/prochand.tex
index e30aff30321ecc136975882ea7e81467c8311f9a..5186e4155337a7da038ea9aa40879f7bb497469f 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -695,7 +695,7 @@ eseguite alla chiusura di un processo 
 \item se la conclusione di un processo rende orfano un \textit{process
     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
 \item se la conclusione di un processo rende orfano un \textit{process
     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}

-  (vedi \secref{sec:sess_xxx}).
+  (vedi \secref{sec:sess_ctrl_term}).

 \end{itemize*}
 
 Oltre queste operazioni è però necessario poter disporre di un meccanismo
 \end{itemize*}
 
 Oltre queste operazioni è però necessario poter disporre di un meccanismo

diff --git a/session.tex b/session.tex
index bb207eb65b6fc03bf757123c732144e5654590ba..2f73d61b53bd790d8a3f0303dcf86eb926c7ac63 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -60,7 +60,7 @@ questo potr
 Per questo l'esecuzione di un comando può originare più di un processo; quindi
 nella gestione del job control non si può far riferimento ai singoli processi.
 Per questo il kernel prevede la possibilità di raggruppare più processi in un
 Per questo l'esecuzione di un comando può originare più di un processo; quindi
 nella gestione del job control non si può far riferimento ai singoli processi.
 Per questo il kernel prevede la possibilità di raggruppare più processi in un

-\textit{process group} (detto anche \textsl{raggruppamento}, vedi
+\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi

 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
 originano da una riga di comando appartengano allo stesso \textit{process
   group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
 originano da una riga di comando appartengano allo stesso \textit{process
   group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal


@@ -279,15 +279,16 @@ controllo.
 
 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
 il precedente terminale di controllo viene cancellata, ed il processo che è
 
 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
 il precedente terminale di controllo viene cancellata, ed il processo che è

-divenuto un nuovo leader di sessione dovrà riottenere (qualora sia necessario,
-cosa che, come vedremo in \secref{sec:sess_daemon}, non è sempre vera), un
-terminale di controllo. In generale questo viene fatto automaticamente dal
-sistema quando viene aperto il primo terminale\footnote{a meno di non avere
-  richiesto esplicitamente che questo non diventi un terminale di controllo
-  con il flag \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux
-  segue la semantica di SVr4; BSD invece richiede che il terminale venga
-  allocato esplicitamente con una \func{ioctl} con il comando
-  \macro{TIOCSCTTY}.} che diventa automaticamente il terminale di controllo,
+divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
+  è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
+  sempre vera}, un terminale di controllo. In generale questo viene fatto
+automaticamente dal sistema\footnote{a meno di non avere richiesto
+  esplicitamente che questo non diventi un terminale di controllo con il flag
+  \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
+  semantica di SVr4; BSD invece richiede che il terminale venga allocato
+  esplicitamente con una \func{ioctl} con il comando \macro{TIOCSCTTY}.}
+quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
+\file{/dev/tty*}) che diventa automaticamente il terminale di controllo,

 mentre il processo diventa il \textsl{processo di controllo} di quella
 sessione.
 
 mentre il processo diventa il \textsl{processo di controllo} di quella
 sessione.
 


@@ -328,9 +329,11 @@ controllo provocher
 lettura o scrittura) a tutto il suo \textit{process group}; dato che il
 comportamento di default di questi segnali (si riveda quanto esposto in
 \secref{sec:sig_job_control}) è di bloccare il processo, di norma questo
 lettura o scrittura) a tutto il suo \textit{process group}; dato che il
 comportamento di default di questi segnali (si riveda quanto esposto in
 \secref{sec:sig_job_control}) è di bloccare il processo, di norma questo

-comporta che tutti verranno fermati, ma non si avranno condizioni di
-errore. Se però si bloccano o ignorano i due segnali citati, le funzioni di
-lettura e scrittura falliranno con un errore di \macro{EIO}.
+comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
+condizioni di errore.\footnote{la shell in genere notifica comunque un
+  avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
+  \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
+funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.

 
 Un processo può contollare qual'è il gruppo di \textit{foreground} associato
 ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
 
 Un processo può contollare qual'è il gruppo di \textit{foreground} associato
 ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:


@@ -393,47 +396,48 @@ essi potranno essere avvisati che non esiste pi
 gestire il terminale (di norma tutto ciò comporta la terminazione anche di
 questi ultimi).
 
 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}.
+Restano però gli eventuali processi in background, che non ricevono il
+segnale; in effetti se il terminale non dovesse più servire essi potrebbero
+proseguire fino al completamento della loro esecuzione; ma si pone il problema
+di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
+terminale, in assenza di un processo che sia in grado di effettuare il
+controllo dello stesso.
+
+Questa è la situazione in cui si ha quello che viene chiamato un
+\textit{orphaned process group}. Lo standard 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
+inoltre che se la terminazione di un processo fa sì che un raggruppamento di
+processi diventi orfano e se i suoi membri sono bloccati, ad essi vengano
+inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}.

 
 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
 
 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
+tutto ciò abbia a che fare con il problema della terminazione del processo di
+controllo.  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 dalla stessa e il nuovo
+process group contiene solo il leader di sessione. Questo è un caso limite, e
+non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
+solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
+processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
+  uscita del processo, come una delle operazioni legate all'esecuzione di
+  \func{_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
+
+Il leader di sessione provvederà a creare nuovi raggruppamenti di processi 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
 \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}.
-
-
-
-
+group creati direttamente dal leader di sessione (a meno di non aver spostato
+con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
+viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali:
+\macro{SIGCONT} ne farà proseguire l'esecuzione, e, essendo stato nel
+frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
+quest'ultimo, essi saranno terminati.

 
 
 
 

- 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}
 
 
 \subsection{Dal login alla shell}